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
>