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
