I'd like to test this later using the ConnectionAcquitionMode. In theory this should led to zero overhead for real applications.
P.S. I had to remove your image as the mailing list does not accept attachments. On Thu, Nov 19, 2015 at 1:11 AM Vlad Mihalcea <mihalcea.v...@gmail.com> wrote: > I wrote a test to replicate the aggressive release overhead ( > https://github.com/vladmihalcea/high-performance-java-persistence/blob/master/core/src/test/java/com/vladmihalcea/book/hpjp/hibernate/connection/jta/JtaConnectionReleaseTest.java > ) 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 <st...@hibernate.org> > 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.v...@gmail.com> >> 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 <st...@hibernate.org> >>> 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.v...@gmail.com> >>>> 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@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
