[hibernate-dev] Sessions sharing Connections

[Shawn Clowater]

I lean towards the proper fix as I think in its current state the
connection() and transactionContext() are not usable at all (especially
with the connection leaks).  In a perfect world it would have been
caught prior to 4 release but that horse has left the barn.

The SPIs like you said are new to 4 so there might not be a whole lot of
people leveraging them, and if they are, they're probably running into
the same types of issues we've been discussing.  (and even worse, might
be hitting them and not noticing)

In the end though, if the concurrency issues are indeed as slight as you
think and the SPI changes aren't acceptable, then it might be worthwhile
to live with that (and document it explicitly) and then fix it properly
when you rev to 5.

-----Original Message-----
From: hibernate-dev-bounces at lists.jboss.org
[mailto:hibernate-dev-bounces at lists.jboss.org] On Behalf Of Steve
Ebersole
Sent: Friday, March 16, 2012 7:28 AM
To: hibernate-dev at lists.jboss.org
Subject: [hibernate-dev] Sessions sharing Connections

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
_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev