Sahil lone opened SPR-13789 and commented

When we use Platform transaction management of Spring , the below example is how we use it.

DefaultTransactionDefinition transactionDefinition = new DefaultTransactionDefinition();
transactionStatus = getTransactionManager().getTransaction(transactionDefinition);
//do ur stuff here
getTransactionManager().commit(transactionStatus);

If we will look above we have to explicitly commit the transaction or rollback it.
In situations where we do not commit or rollback the transaction ; the transaction status is attached to thread and not removed on returning the thread to pool. As we already know only the owner function (function which started the transaction) can commit or rollback the transaction ; so when the transaction commit or rollback is missed , next time when the thread is again taken from pool and the thread is not recycled before reusing then the old transaction status is returned with thread . So any new transaction in case on TransactionDefinition.PROPAGATION_REQUIRED gives older transaction status and the current function calling the tx Manager doesn't become owner. So when the work is done and the function tries to commit or rollback , the transaction is niot actually commited. Because of this behaviour it leads to inconsistencies in data which developer is not aware.

This issue is because TransactionSynchronizationManager ie spring transaction management uses lot of thread local variable so the variable are not reset if transaction is not marked as completed.

There may be use cases where this behaviour maybe needed ie spaning transactions across thread reuse or across equests in case of serveet containers. But let me put this point that we can't be sure when thread variable will be garbage collected as it uses weak reference for thread local variables.

I have designed a Utility class for my project which takes care or these issues and ask for configuration o enable the utility and what to when transaction is missed.

Affects: 3.0.7

Issue Links:

• Prevent corrupted ThreadLocals when mis-using triggerAfterCommit [SPR-11761] #16383 Prevent corrupted ThreadLocals when mis-using triggerAfterCommit

0 votes, 5 watchers