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.v...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
