Standardmäßig sollte das von Ihnen beschriebene Verhalten unmöglich sein – Änderungen, die in einer festgeschriebenen Transaktion vorgenommen werden, werden sofort für alle Sitzungen verfügbar. Es gibt jedoch Ausnahmen:
-
Verwenden Sie eine der WRITE-Optionen im COMMIT-Befehl? Ist dies nicht der Fall, bestätigen Sie den Wert Ihres Initialisierungsparameters COMMIT_WRITE. Wenn entweder "WRITE BATCH" oder insbesondere "WRITE BATCH NOWAIT" verwendet wird, könnten Sie sich für Parallelitätsprobleme öffnen. "WRITE BATCH NOWAIT" wird normalerweise in Fällen verwendet, in denen die Geschwindigkeit Ihrer Schreibtransaktionen wichtiger ist als mögliche Parallelitätsprobleme. Wenn Ihr Initialisierungsparameter die "WRITE"-Varianten verwendet, können Sie ihn auf Transaktionsbasis überschreiben, indem Sie die IMMEDIATE-Klausel in Ihren Commits angeben (siehe COMMIT)
-
Ruft die Transaktion, die versucht, die Daten zu lesen, SET TRANSACTION auf, bevor die andere Transaktion festgeschrieben wird? Die Verwendung von SET TRANSACTION zur Angabe von SERIALIZATION LEVEL READ ONLY oder SERIALIZABLE führt dazu, dass die Transaktion keine Änderungen von anderen festgeschriebenen Sitzungen sieht, die nach dem Aufruf von SET TRANSACTION aufgetreten sind (siehe SET TRANSACTION)
Bearbeiten:Ich sehe, dass Sie eine DataSource-Klasse verwenden. Ich bin mit dieser Klasse nicht vertraut - ich nehme an, es handelt sich um eine Ressource zur gemeinsamen Nutzung von Verbindungen. Mir ist klar, dass Ihr aktuelles App-Design es möglicherweise nicht einfach macht, dasselbe Verbindungsobjekt während Ihres gesamten Arbeitsablaufs zu verwenden (die Schritte können so konzipiert sein, dass sie unabhängig voneinander funktionieren, und Sie haben keine Einrichtung eingebaut, um ein Verbindungsobjekt von einem Schritt an den zu übergeben next), aber Sie sollten sicherstellen, dass Verbindungsobjekte, die an das DataSource-Objekt zurückgegeben werden, "sauber" sind, insbesondere im Hinblick auf offene Transaktionen. Es ist möglich, dass Sie SET TRANSACTION nicht in Ihrem Code aufrufen, aber ein anderer Verbraucher von DataSource an anderer Stelle dies tut und die Verbindung zurück zur Datenquelle mit der Sitzung zurückgibt, die sich noch im SERIALIZABLE- oder READ ONLY-Modus befindet. Bei der gemeinsamen Nutzung von Verbindungen müssen alle Verbindungen unbedingt zurückgesetzt werden, bevor sie an einen neuen Verbraucher übergeben werden.
Wenn Sie das Verhalten der DataSource-Klasse nicht kontrollieren oder einsehen können, sollten Sie versuchen, ein ROLLBACK für die neu erworbene Verbindung auszuführen, um sicherzustellen, dass keine verbleibende Transaktion bereits eingerichtet wurde.
