-
-
Notifications
You must be signed in to change notification settings - Fork 336
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
InTransaction does not call transactionHandler.inTransaction when initalAutoCommit=false #2663
Comments
Hi @RezaLabudeBSM , I am sorry you had troubles with this behavior. Can you explain a bit more about what you're trying to achieve by turning autocommit off? |
We have bad experiences with this auto-commit feature and therefore generally turn it off (we do this right a the start when we configure hikari to tell it that auto-commit should be turned off for all connection in this pool), so that we can decide in the transactions when it has to be commited or roll back. We use JPA, JDBC Template and now JDBI, so there are many different persistence technologies in our stack. |
I just understood that you expect not to change this value so that JDBI can use it to signal wether a transaction is already running or not in the case of nested transactions. But i think that using the auto-commit status as an indicator is not the right way. As i said: it is very easy to configure Hikari in such a way that every connection it issues has the auto-commit set to false and i also think that it is a valid useage of the connection. |
Thanks for the feedback. This is currently not supported, as you note, but we can consider changing this in the future. This isn't the first time this has been requested. |
When you have configured a connection which has autoCommit=false then you can not use the
handle.inTransaction as expected, as it never calls commit. You must explizitly call commit to actually commit the changes.
I debugged this issue and found out that the relevant method
inTransaction
never gets to thetransactionHandler.inTransaction
part:The reason is this check:
The second OR part is always true for a connection which has been set to AutoCommit false.
This problem is not seen as there is no real tests which verifies that a connection with AutoCommit = false actually calls commit.
I would therefore suggest to add this test:
My Bugfix would be to remove the || !handle.getConnection().getAutoCommit() and trust the enum statemachine.
(This text is a summary of my findings in #2662)
The text was updated successfully, but these errors were encountered: