[hibernate-dev] Sessions sharing Connections
Steve Ebersole
steve at hibernate.org
Mon Mar 19 11:36:41 EDT 2012
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
More information about the hibernate-dev
mailing list