Open mrohan01 opened 3 years ago
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 https://github.com/supercargo/guice-persist-jooq/blob/6e8f67bc09fcf6fa5170341f1cc95c420b3db2bd/src/main/java/com/adamlewis/guice/persist/jooq/JdbcLocalTxnInterceptor.java#L71 ?
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.
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!