1:45 a.m.
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
8:05 a.m.
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>
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
9:18 a.m.
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> 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>
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
>
9:49 a.m.
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>
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>
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>
> 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
>>
>
3311
days inactive
3311
days old
3 comments
2 participants
participants (2)
-
Steve Ebersole -
Vlad Mihalcea