Por padrão, o comportamento que você descreveu deve ser impossível - as alterações feitas em uma transação confirmada ficam disponíveis imediatamente para todas as sessões. No entanto, existem exceções:
-
Você está usando alguma das opções WRITE no comando COMMIT? Se não estiver, confirme o valor de seu parâmetro de inicialização COMMIT_WRITE. Se um deles estiver usando o "WRITE BATCH" ou especialmente "WRITE BATCH NOWAIT", você pode estar se abrindo para problemas de simultaneidade. "WRITE BATCH NOWAIT" normalmente seria usado nos casos em que a velocidade de suas transações de gravação é mais importante do que possíveis problemas de simultaneidade. Se o seu parâmetro de inicialização estiver usando as variantes "WRITE", você poderá substituí-lo em uma transação especificando a cláusula IMMEDIATE em seus commits (consulte COMMIT)
-
A transação que está tentando ler os dados está invocando SET TRANSACTION antes da confirmação da outra transação? Usar SET TRANSACTION para especificar SERIALIZATION LEVEL READ ONLY ou SERIALIZABLE fará com que a transação não veja as alterações que ocorrem de outras sessões confirmadas que ocorreram após a invocação de SET TRANSACTION (consulte SET TRANSACTION)
edit:vejo que você está usando uma classe DataSource. Não estou familiarizado com esta classe - suponho que seja um recurso de compartilhamento de conexão. Percebo que o design de seu aplicativo atual pode não facilitar o uso do mesmo objeto de conexão em todo o fluxo de trabalho (as etapas podem ser projetadas para operar de forma independente e você não criou um recurso para passar um objeto de conexão de uma etapa para a a seguir), mas você deve verificar se os objetos de conexão que estão sendo retornados ao objeto DataSource estão "limpos", especialmente no que diz respeito às transações abertas. Pode ser possível que você não esteja invocando SET TRANSACTION em seu código, mas outro consumidor de DataSource em outro lugar pode estar fazendo isso e retornando a conexão de volta para a fonte de dados com a sessão ainda no modo SERIALIZABLE ou READ ONLY. Ao compartilhar a conexão, é imperativo que todas as conexões sejam revertidas antes de entregá-las a um novo consumidor.
Se você não tem controle ou visibilidade do comportamento da classe DataSource, você pode tentar executar um ROLLBACK na conexão recém-adquirida para garantir que não haja nenhuma transação remanescente já estabelecida.
