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