[ https://hibernate.onjira.com/browse/HHH-7090?page=com.atlassian.jira.plug... ] Shawn Clowater commented on HHH-7090: ------------------------------------- Ok, I've drilled around in this a bit and I think I have a semi handle on what the issue is. When the sessionWithOptions().transactionConext() is called it sets a shareTransactionContext on the SharedSessionBuilderImpl to true which passes the current TransactionCoordinatorImpl in the secondary SessionImpl constructor. Since TransactionCoordinatorImpl isn't null it just simply sets it on the second session. The TransactionCoordinatorImpl keeps a reference to the TransactionContext when it is first built, which is actually the original session. This is why when the second session calls close on the TransactionCoordinator it closes the main session. I toyed with providing a SharedTransactionContextSessionWrapper that gets built in the following manner from the SharedSessionBuilderImpl {code} @Override public Session openSession() { return shareTransactionContext ? new SharedTransactionContextSessionWrapper(super.openSession()) : super.openSession(); } {code} So, if the context is shared it wraps the session and delegates to it. To fix the first test I simply overrode the close {code} @Override public Connection close() throws HibernateException { LOG.trace("Closing session"); if (delegate.isClosed()) { throw new SessionException("Session was already closed"); } if (getSessionFactory().getStatistics().isStatisticsEnabled()) { delegate.getSessionFactory().getStatisticsImplementor().closeSession(); } delegate.setClosed(); delegate.cleanup(); //can't provide a user connection and have a shared transaction context so just return null return null; } {code} I originally looked at wrapping the TransactionCoordinator but the SessionImpl consumes a TransactionCoordinatorImpl and not the interface so it started to get a bit messy so I went the Session route to see if I could get close. With this change it did fix the first attached test since the transactionCoordinator.close() is now not called. I then took a look at the second test which seemed to suggest that the auto close of the session might not quite work and that is, in fact, the case. Again, since the TransactionCoordinator only keeps track of the one TransactionContext (i.e. the first session), the secondary session never has managedClose() called on it. I believe not manually closing the second session and then defining it as autoClose is the suggested workaround but I can't see how it would get closed since the TransactionCoordinator doesn't know anything about it. So it's a bit of a catch 22 in the current implementation. You can't close the secondary session since it will auto close the transaction but then you can't depend on the auto close of the session from transaction commit. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-7090?page=com.atlassian.jira.plug... ] Steve Ebersole commented on HHH-7090: ------------------------------------- Same thing with "auto join transactions" -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-7090?page=com.atlassian.jira.plug... ] Steve Ebersole commented on HHH-7090: ------------------------------------- We may want to do something with protecting session.getTransaction calls on the "non primary session", but aside from that sharing a "transaction context" is actually working -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira