I wrote a test to replicate the aggressive release overhead ( https://github.com/vladmihalcea/high-performance-java-persistence/blob/ma... ) and these are my findings: ​ The more statements a transaction has, the more obvious the performance impact. This was tested with Spring and Bitronix and so it measures Bitronix overhead. We'll have to update the docs to advise the clients to consider the AFTER_TRANSACTION mode for some stand-alone JTA environments. I wonder if today's Java EE application servers still require the aggressive release as an workaround to their connection leak detection algorithms. Vlad On Wed, Nov 18, 2015 at 5:49 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Yes, I think that's a good idea. I also think working > on ConnectionAcquisitionMode is the best option. The fact that Hibernate > delays getting the Connection is so generally not useful. > > > On Wed, Nov 18, 2015 at 9:42 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; > wrote: > >> Thanks for the explanation. I found a discussion from 2006 where you >> explained this behavior: >> >> http://lists.jboss.org/pipermail/hibernate-dev/2006-December/000903.html >> >> I am currently testing the AFTER_TRANSACTION release mode with Spring >> and Bitronix and I think it can give some performance gain over >> AFTER_STATEMENT. >> I'll keep you posted with the final results. >> >> Do you think we should update the docs to explain that this is rather >> required by Java EE containers, and it might be fine with stand-along JTA >> transaction managers? >> >> Vlad >> >> >> >> On Wed, Nov 18, 2015 at 4:05 PM, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> It was to work around certain containers (not just EE containers) that >>> implement "resource containment" checks. The Hibernate Session defers >>> getting a JDBC Connection until it actually needs one, which can lead to >>> cases like the following where 2 beans share a Session/EM: >>> >>> Bean1: get Session, but don't use it yet in way that needs Connection >>> Bean1: call Bean2... >>> Bean2: get Session, do some work forcing Session to obtain Connection >>> Bean2: return (Session still hold Connection) >>> >>> At this point, these containers see this as a "leaked" Connection >>> because the handle was not released by the end of the scope in which it was >>> obtained. Hence, aggressive releasing. My contention at the time was that >>> a ConnectionAcquisitionMode would have been better/cleaner. I still feel >>> that way, and hope to still come back and add that; so much so in fact that >>> the enum already exists[1] :). >>> >>> [1] org.hibernate.ConnectionAcquisitionMode >>> >>> On Wed, Nov 18, 2015 at 1:45 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; >>> wrote: >>> >>>> Hi, >>>> >>>> Does anyone remember why does Hibernate support aggressive connection >>>> releasing? >>>> I've never found this requirement in either JTA or JDBC spec. >>>> Was it something required by the Java EE application server? >>>> >>>> Vlad >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>