[hibernate-dev] Why does Hibernate has aggressive connection releasing for JTA

[Steve Ebersole]

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.vlad at 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 <steve at 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.vlad at 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 <steve at 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.vlad at 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>
>