If we associate the db connection with the JTA transaction, I assume that we would release the connection after the transaction completes.
On 10/15/2012 01:47 PM, Scott Marlow wrote: > If we have a bean (topbean) invoking another bean (childbean) method > that needs a new JTA transaction > (http://docs.oracle.com/javaee/6/api/javax/ejb/TransactionAttributeType.html#REQUIRES_NEW), > we will want to use separate database connections for the two beans. > > I think that this would only be a requirement if a (container managed) > extended persistence context is used since two separate Hibernate > sessions would be used if the persistence context is transaction scoped. > > If we are in a JTA transaction, I think that associating the connection > with the transaction could be an alternative to associating the > connection with the session. > > On 10/15/2012 12:30 PM, Steve Ebersole wrote: >> Was thinking some more today about the deprecation of Session.connection() >> >> The reason we deprecated it was that we need a way to scope access to >> the Connection because Session may have to release it due to "release >> mode". The back story here is that we added "connection release mode" >> as a way to fix an earlier problem using Hibernate in certain >> container-managed-transaction scenarios involving nested bean calls >> where they both used the same Session but the nested bean forced the >> session to obtain a Connection first. Hibernate tries to delay >> obtaining the JDBC Connection until needed. However, in the stated >> scenario that leads to a situation where the container managing the >> transaction sees a Connection "leaking" from the nested bean call since >> it was the one that forced the Connection to be obtained from the >> DataSource. The solution to this back then was to have Hibernate >> release the Connection whenever it was done using it for the moment in >> JTA cases. In retrospect, I think a much cleaner solution to the above >> situation is to force the Session to obtain the Connection up front >> rather than this obtain/release as-needed cycle. >> >> So as one more attempt to save Session.connection() from going away, I >> wanted to propose that we drop the notion of "release mode" in favor of >> simply saying whether or not to aggressively acquire the Connection when >> the Session starts. Then all of the concerns that made deprecating and >> planning on removing Session.connection() are no longer there. >> >> WDYT? >> >> > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
