Hello,
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
Thanks
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
Thanks