ConnectionLifecycleInterceptor and transactionBegun
Date: October 04, 2012 12:07PM
I implemented com.mysql.jdbc.ConnectionLifecycleInterceptor (and I should thank the connector-j team for that -- it has saved me hours from having to trace through Hibernate/Spring code), and I was intrigued by the lifecycle method #transactionBegun
the javadoc reads:
* Called when the driver has been told by the server that a transaction
* is now in progress (when one has not been currently in progress).
Can I interpret that literally? Meaning that there is actually a response from the server (something like "TRANSACTION BEGUN")?
If log order is to be trusted, it looks like #transactionBegun() is invoked AFTER executing a SELECT query (and I'm presuming is similar for CUD methods). The relevant point is it DOES NOT occur immediately after a Connection.setAutoCommit(false) call
This got me to thinking: when actually does a transaction start? Or more relevantly, when does a transaction's "snapshot" begin (I almost exclusively use transaction isolation level REPEATABLE-READ, which is better thought of as snapshot isolation).
Since jdbc.Connection has no #startTransaction() method, #setAutocommit(false) is essentially used as a (poor) surrogate. But there is a lot to be said for the driver/server delaying the actual transaction start (read snapshot's beginning) until a "transaction-inducing command" (CRUD) is issued.
Think of a connection-pool where the jdbc Connection is in the pool with its #setAutoCommit(false) flag being set. It might be sitting there for hours and obviously you would not want the snapshot to already have begun in such a case.
Any information/link you could provide would be appreciated; it's more curiosity on my part than anything.
BTW, there is also a #transactionCompleted method on ConnectionLifecycleInterceptor, but at least upon a transaction that only issues SELECTs, it is never invoked (even when there is an explicit jdbc.Connection.commit()) call
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.