[hibernate-dev] Sessions sharing Connections

[Steve Ebersole]

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?
>>>
>>
>

-- 
steve at hibernate.org
http://hibernate.org