Par défaut, le comportement que vous avez décrit devrait être impossible - les modifications apportées à une transaction validée deviennent immédiatement disponibles pour toutes les sessions. Cependant, il existe des exceptions :
-
Utilisez-vous l'une des options WRITE de la commande COMMIT ? Si ce n'est pas le cas, confirmez la valeur de votre paramètre d'initialisation COMMIT_WRITE. Si l'un ou l'autre utilise le "WRITE BATCH" ou surtout "WRITE BATCH NOWAIT", vous pourriez vous exposer à des problèmes de concurrence. "WRITE BATCH NOWAIT" est généralement utilisé dans les cas où la vitesse de vos transactions d'écriture est plus importante que les éventuels problèmes de concurrence. Si votre paramètre d'initialisation utilise les variantes "WRITE", vous pouvez le remplacer sur une base transactionnelle en spécifiant la clause IMMEDIATE dans vos commits (voir COMMIT)
-
La transaction qui tente de lire les données appelle-t-elle SET TRANSACTION avant que l'autre transaction ne soit validée ? L'utilisation de SET TRANSACTION pour spécifier SERIALIZATION LEVEL READ ONLY ou SERIALIZABLE entraînera que la transaction ne verra aucun changement qui se produit à partir d'autres sessions validées qui se sont produites après l'appel de SET TRANSACTION (voir SET TRANSACTION)
edit :je vois que vous utilisez une classe DataSource. Je ne connais pas cette classe - je suppose que c'est une ressource de partage de connexion. Je me rends compte que la conception actuelle de votre application peut ne pas faciliter l'utilisation du même objet de connexion tout au long de votre flux de travail (les étapes peuvent être conçues pour fonctionner indépendamment et vous n'avez pas intégré de fonctionnalité pour transmettre un objet de connexion d'une étape à la next), mais vous devez vérifier que les objets de connexion renvoyés à l'objet DataSource sont "propres", en particulier en ce qui concerne les transactions ouvertes. Il est possible que vous n'appeliez pas SET TRANSACTION dans votre code, mais qu'un autre consommateur de DataSource le fasse ailleurs et renvoie la connexion à la source de données avec la session toujours en mode SERIALIZABLE ou READ ONLY. Lors du partage de connexion, il est impératif que toutes les connexions soient annulées avant de les transférer à un nouveau consommateur.
Si vous n'avez aucun contrôle ou visibilité sur le comportement de la classe DataSource, vous pouvez essayer d'exécuter un ROLLBACK sur la connexion nouvellement acquise pour vous assurer qu'il n'y a pas de transaction persistante déjà établie.
