That sounds great. I'll have to write about it in the 5.0 documentation. Vlad
On Mon, Nov 30, 2015 at 9:10 PM, Steve Ebersole <st...@hibernate.org> wrote: > 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
