https://issues.apache.org/bugzilla/show_bug.cgi?id=53523
--- Comment #4 from Anjana Fernando <laferna...@gmail.com> --- Hi Filip, Thank you for your detailed response. For my requirement, I'm guessing I will have to use the custom JDBC interceptor approach. Because, in the connection pool usage, the applications which use it, the user may set autoCommit to false and commit at the end, and in a finally block, he will close the connection. So if there was an error and the execution just jumps to the finally and closes the connection, the commit won't be called and the connection will just return to the pool without being committed or rollbacked. And as for having defaultAutoCommit=true and using the ConnectioState interceptor, I'm a bit uneasy in keeping dirty connections in the pool :) .. How I got this situation was with MySQL/InnoDB, where they use REPEATABLE_READ transaction isolation level by default, which causes unexpected situations like a written value cannot be read by another connection and so on, if the connections aren't properly committed/rollbacked. Cheers, Anjana. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
