As for the "how"... This happens when the user wants to open a session reusing pieces of another session. This is the org.hibernate.SharedSessionBuilder stuff. See org.hibernate.Session#sessionWithOptions if you are not familiar.
On Mon 19 Mar 2012 10:36:41 AM CDT, Steve Ebersole wrote: > Well there are 2 options listed in the original email. So depends on > which option you mean. Both options require some SPI changes. > Actually, in the more minor one we could probably get away with > retrofitting the old SPI methods via delegation+deprecation. > > Currently, Session maintains a TransactionCoordinator which in turn > maintains a JdbcCoordinator which in turn maintains a LogicalConnection. > > Option 1 would invert the relationship between these contracts, which > in retrospect I think is more correct. Going this route, I think I > would also rename JdbcCoordinator to JdbcSession (in honor of the fact > that it really models what most databases term a "session" which is > what a JDBC Connection and transaction is to them). Session would then > maintain reference to this JdbcSession. JdbcSession would hold both > the LogicalConnection and TransactionCoordinator as well as the Batch > information. It could either be passed a LogicalConnection and > TransactionCoordinator or generate new ones. > > Option 2 would just retrofit the notion of sharing LogicalConnection > and TransactionCoordinator while using unique JdbcCoordinator while as > little disruption to the existing SPIs as possible. TBH not even sure > this option is feasible. > > > > On Mon 19 Mar 2012 09:51:50 AM CDT, Scott Marlow wrote: >> Which SPIs would change? JdbcCoordinator and TransactionCoordinator? >> >> How do we get into the situation of having 2 sessions share a JDBC >> connection? Does this impact both JPA and Hibernate native based >> applications? >> >> On 03/16/2012 09:27 AM, Steve Ebersole wrote: >>> Reference https://hibernate.onjira.com/browse/HHH-7020 and >>> https://hibernate.onjira.com/browse/HHH-7090... >>> >>> Essentially, having 2 sessions share a JDBC connection is currently >>> broken. Adam, Lukasz and I discussed this on the mailing list a few >>> months ago and Shawn has been helping me investigating the last few >>> days. The solution end solution is to have the 2 sessions share both >>> the TransactionCoordinator and LogicalConnection, but use separate >>> JdbcCoordinators. >>> >>> We could get away with them sharing a JdbcCoordinator as well, but that >>> opens up (slight) potential concurrency issues if the 2 sessions are >>> used concurrently. The concurrency issues here are not on the same >>> level as those if using a session concurrently. Mainly JdbcCoordinator >>> manages the "current JDBC batch" if the session is using JDBC statement >>> batching. Concurrent access could mean batch circumvention (aka, 1 >>> statement executed in the batch instead of the batch size) if both >>> sessions are performing writes concurrently. >>> >>> All the above is a bit specific, but the ultimate question/decision >>> here >>> is that in order to not reuse JdbcCoordinators requires *major* SPI >>> changes. Basically we need to invert the relationship between >>> JdbcCoordinator and TransactionCoordinator. Currently Session holds a >>> TransactionCoordinator and that TransactionCoordinator is responsible >>> for managing the JdbcCoordinator. The "proper" change would require >>> that instead Session hold a JdbcCoordinator which is responsible for >>> managing a TransactionCoordinator. >>> >>> A consideration here is that these are SPIs and should not really be >>> changing between point releases. But another thing to consider is that >>> these particular SPIs were added in 4.0, so they are relatively new, >>> and >>> that, in this particular case at least, they are just plain wrong. >>> >>> What do y'all think between these 2 options? >>> >> > -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
