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

[Vlad Mihalcea]

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 <steve at 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.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
>>>>>>
>>>>>
>>>>
>>