inTransaction is not working when not using commit() for inital autoCommit = false connections; #2662
Replies: 4 comments
-
After some debugging and experimenting, i think i found the problem: `
` ` public <R, X extends Exception> R inTransaction(HandleCallback<R, X> callback) throws X { ` it has already a started transaction and never gets to the transactionHandler.inTransaction which does the begin and commit as expected. So my question is why do you do this kind of initialisation? it looks like someone wanted to save thereby the call to the begin() method as the connection is already setAutoCommit(false) and therefore the handlerState can go directly to AFTER_BEGIN, but with this "optimisation" the inTransaction does not work correctly anymore. |
Beta Was this translation helpful? Give feedback.
-
I checked the code and this behaviour was introduced because of #2491. But with this inital setting of handlerState to AFTER_BEGIN there is no chance that the code inside of transactionHandler.inTransaction will be called as this check will return true because of the second false for getAutoCommit: `
` The problem that there is no test that tests, whether a commit() is called, when autocommit() is set to false.
` I tested it with the actual implemention and now you have a failing test |
Beta Was this translation helpful? Give feedback.
-
My suggestion to fix this problem would be to remove the || !handle.getConnection().getAutoCommit() as this code was from the previous implementation without the statemachine via the enum. Now you have this enum and you should trust its state to observe the state of the transaction correctly. Otherwise it will be difficult to solve this problem for both autoCommit states. |
Beta Was this translation helpful? Give feedback.
-
This is filed as issue #2663 - let's keep the conversation in one place. |
Beta Was this translation helpful? Give feedback.
-
Hello,
and again another problem i do not understand why i can not get it to work correctly:
The Working Code which really deletes the rows in the database after the explicit commit:
`
`
with this stacktrace:
I then changed the code without the explicit begin and commit
`
`
But this time the delete is not commited in the database and therefore not persisted = the rows are still there and not deleted.
The stacktrace is the same and does also have the inTranscation
So why is the second example not working. As far as i understood it is not necessary to use exlicit transaction commands begin and commit.
(I'm running in a spring boot container, but i did not use the TransactionAwareDataSourceProxy and want to rely on the JDBI transaction management (when i activate this Proxy, then it works correctly with the Spring @transactional Annotation, but this is not what i want))
Beta Was this translation helpful? Give feedback.
All reactions