Doesn't work correctly with connections defaulted to autoCommit=false
mrohan01 opened this issue · comments
When using with connections obtained from a connection pool configured with autoCommit=false by default, the transaction interceptor doesn't work correctly.
Adding a local variable to determine whether the transaction was started by the current interceptor execution (and should be committed / rolled back after the proxied method execution returns), and a variable identifying if auto commit should be re-enabled or not, allows this to work without relying on the current setting of autoCommit.
If this seems reasonable, I'm happy to put up a PR. Thanks!
I'm a bit unclear on the transaction boundaries you're suggesting...the autoCommit flag is currently used to determine if the interceptor should be managing the transaction lifecycle, or not. Are you suggesting that you want the interceptor to manage a transaction lifecycle even when auto commit is disabled? i.e. something other than what's done on
I'm happy to look at a PR and if it is a matter of correctness / bugginess I'm happy to incorporate the change. Test cases are always nice, too :)
If it is just a matter of preference or adding use cases, I wonder if it makes sense to facilitate alternate implementations of some object/interface to be injected so that consumers of the library can tailor to their needs.