[hibernate-dev] Connection release modes

[Steve Ebersole]

I don't understand the statement about "auto-commit mode connection
release".  The idea with the implied auto-commit connection release mode
is that in the case of auto-commit transaction control, there is really
no need to have the same connection for each operation as long as we are
not batching and not generally holding open JDBC resources.  What makes
you say it appears to happen for just a few operations?

"With a Java transaction manager we have to give back the connection
after every SQL statement" => That's not completely true.  The reason we
introduced this behavior was to circumvent "resource containment checks"
in environments which do such things (JBoss, WebLogic and WebSphere app
servers for example).  "resource containment who-whats"?  ;)  Well there
is a usage pattern which used to cause Hibernate users problems in such
environments.  Consider the case of an EJB application using Hibernate
where the EJBs call one another; something like:
SessionBeanA {
    public void doSomething() {
        Session s = ...;
        SessionBeanB b = ...;
        b.doSomethingElse();
    }
}

SessionBeanB {
    public void doSomethingElse() {
        Session s = ...;
        s.load( MyEntity.class, "myKey" );
        // do some more work and return
    }
}

Pretty innocuous, right?  The problem lies in the fact that the Session
did not actually obtain a JDBC connection until the execution of
SessionBeanB.doSomethingElse() since it delays getting a connection
until needed.  The problem, from the perspective of environments which
do perform resource containment checks, is that we just leaked a
resource... the connection!  The connection was retrieved from the DS
during the execution of SessionBeanB.doSomethingElse(), but is not
released by the time SessionBeanB.doSomethingElse() completes execution.


And just to round out the discussion, I do not know how this works in
the .Net corollaries, but after_transaction should not be used in the
case of some form of managed transaction and transacted datasources.
Doing so would cause Hibernate to try and release its connection handle
during the Synchronization.afterCompletion callback, which is
disallowed.



-----Original Message-----
From: hibernate-dev-bounces at lists.jboss.org
[mailto:hibernate-dev-bounces at lists.jboss.org] On Behalf Of Christian
Bauer
Sent: Wednesday, December 13, 2006 5:56 AM
To: the NHibernate development list; hibernate
Subject: [hibernate-dev] Connection release modes

Bringing the two lists together for this thread.

On Dec 13, 2006, at 12:01 PM, Sergey Koshcheyev wrote:

> Christian Bauer wrote:
>> Maybe NHibernate only needs two modes. NHibernate probably only need
>> to release either after transaction (also auto-committed) and when
>> the Session is closed.
> By the way, after reading the Hibernate source, it looks to me that
> auto-commit mode connection release only happens for a few  
> operations on
> the session, not all of them (for example refresh, lock, get with
> LockMode seem to be exempt). Was this intended (why?) or was this an
> oversight?
>
>> With a Java transaction manager we have to
>> give back the connection after every SQL statement. The service
>> guarantees that we will get back "the same" connection inside the
>> same transaction, for the next SQL statement. Is that common in .NET
>> environments?
>>
> As far as I know, it is not.
>
> Sergey

_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev