Domyślnie opisane zachowanie powinno być niemożliwe - zmiany dokonane w zatwierdzonej transakcji stają się natychmiast dostępne dla wszystkich sesji. Istnieją jednak wyjątki:
-
Czy używasz którejkolwiek z opcji WRITE w poleceniu COMMIT? Jeśli nie, potwierdź wartość parametru inicjującego COMMIT_WRITE. Jeśli któryś z nich korzysta z opcji „WRITE BATCH”, a zwłaszcza „WRITE BATCH NOWAIT”, możesz narażać się na problemy ze współbieżnością. „WRITE BATCH NOWAIT” jest zwykle używane w przypadkach, w których szybkość transakcji zapisu ma większe znaczenie niż możliwe problemy ze współbieżnością. Jeśli twój parametr inicjujący używa wariantów "WRITE", możesz go zastąpić na podstawie transakcji, określając klauzulę IMMEDIATE w swoich zatwierdzeniach (zobacz COMMIT)
-
Czy transakcja, która próbuje odczytać dane, wywołuje SET TRANSACTION przed zatwierdzeniem innej transakcji? Użycie SET TRANSACTION do określenia SERIALIZATION LEVEL TYLKO DO ODCZYTU lub SERIALIZABLE spowoduje, że transakcja nie zobaczy żadnych zmian, które nastąpiły z innych zatwierdzonych sesji, które wystąpiły po wywołaniu SET TRANSACTION (patrz SET TRANSACTION)
edit:Widzę, że używasz klasy DataSource. Nie znam tej klasy — zakładam, że jest to zasób udostępniania połączenia. Zdaję sobie sprawę, że Twój obecny projekt aplikacji może nie ułatwiać korzystania z tego samego obiektu połączenia w całym przepływie pracy (kroki mogą być zaprojektowane tak, aby działały niezależnie, a Ty nie zbudowałeś funkcji umożliwiającej przekazywanie obiektu połączenia z jednego kroku do następnie), ale należy sprawdzić, czy obiekty połączeń zwracane do obiektu DataSource są „czyste”, zwłaszcza w odniesieniu do otwartych transakcji. Możliwe, że nie wywołujesz SET TRANSACTION w swoim kodzie, ale inny użytkownik DataSource w innym miejscu może to robić i zwracać połączenie z powrotem do źródła danych, gdy sesja jest nadal w trybie SERIALIZABLE lub READ ONLY. Podczas udostępniania połączenia konieczne jest cofnięcie wszystkich połączeń przed przekazaniem ich nowemu konsumentowi.
Jeśli nie masz kontroli ani widoczności zachowania klasy DataSource, możesz spróbować wykonać ROLLBACK na nowo uzyskanym połączeniu, aby upewnić się, że nie ma już ustanowionej utrzymującej się transakcji.
