[hibernate-dev] Sessions sharing Connections

[Steve Ebersole]

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