De forma predeterminada, el comportamiento que describió debería ser imposible:los cambios realizados en una transacción confirmada estarán disponibles de inmediato para todas las sesiones. Sin embargo, hay excepciones:
-
¿Está utilizando alguna de las opciones de ESCRITURA en el comando COMMIT? Si no es así, confirme el valor de su parámetro de inicialización COMMIT_WRITE. Si está utilizando "ESCRIBIR LOTE" o especialmente "ESCRIBIR LOTE AHORA", podría estar abriéndose a problemas de concurrencia. "WRITE BATCH NOWAIT" normalmente se usaría en casos en los que la velocidad de sus transacciones de escritura es más importante que los posibles problemas de concurrencia. Si su parámetro de inicialización usa las variantes "WRITE", puede anularlo en una transacción especificando la cláusula IMMEDIATE en sus confirmaciones (ver COMMIT)
-
¿La transacción que intenta leer los datos está invocando SET TRANSACTION antes de que se confirme la otra transacción? El uso de SET TRANSACTION para especificar SERIALIZATION LEVEL READ ONLY o SERIALIZABLE dará como resultado que la transacción no vea cambios que ocurran desde otras sesiones comprometidas que ocurrieron después de la invocación de SET TRANSACTION (ver SET TRANSACTION)
editar:veo que estás usando una clase DataSource. No estoy familiarizado con esta clase; supongo que es un recurso para compartir conexiones. Me doy cuenta de que el diseño de su aplicación actual puede no facilitar el uso del mismo objeto de conexión a lo largo de su flujo de trabajo (los pasos pueden estar diseñados para funcionar de forma independiente, y usted no incorporó una instalación para pasar un objeto de conexión de un paso al siguiente). siguiente), pero debe verificar que los objetos de conexión que se devuelven al objeto DataSource estén "limpios", especialmente con respecto a las transacciones abiertas. Es posible que no esté invocando SET TRANSACTION en su código, pero otro consumidor de DataSource en otro lugar puede estar haciéndolo y devolviendo la conexión a la fuente de datos con la sesión aún en modo SERIALIZABLE o READ ONLY. Cuando se comparte la conexión, es imperativo que todas las conexiones se reviertan antes de transferirlas a un nuevo consumidor.
Si no tiene control o visibilidad del comportamiento de la clase DataSource, puede intentar ejecutar un ROLLBACK en la conexión recién adquirida para asegurarse de que no haya una transacción persistente ya establecida.
