Re: [Hibernate-devel] datasources & connection leakage & EJB transactions

[Brad C. <bra...@wo...>]

thanx gavin.  yes i think u r right (i am getting good @ saying that :-))

btw. i wasn't referring to hibernate's own connection pooling.

so assuming a datasource is being utilised, the code to do a simple object
save would look something like:

        Session session = null;
        try {
            session = sessionFactory.openSession();
            session.save(object);
            session.commit();
        }
        catch(SQLException e) {
            ....
        }
        catch(Exception e) {
            ....
        }
        finally
        {
            if (session.isOpen()) {
                try {
                    session.cancel();
                }
                catch (Exception e) {
                    ....
                }
            }
        }

i was orginally thinking that it might be better to split out flushing &
connection closing into their own public methods.  however, this would make
the usage of the session API more complicated, given the different
connection options.  need to think about this some more.  so like u wrote,
perhaps the best solution is adding to the documentation.  a code example
(something like above) with an explanation paragraph for each secenario
(datasource, supplying your own connection) might do the trick.

brad

----- Original Message -----
From: <Gavin_King/Cirrus%CI...@ci...>
To: "Brad Clow" <bra...@wo...>
Cc: <hib...@li...>
Sent: Thursday, February 28, 2002 12:23 PM
Subject: Re: [Hibernate-devel] datasources & connection leakage & EJB
transactions


>
> The cancel() method should be called in a finally block. I think that
> does what you require....
>
> Unless you have provided your own connection, commit() and cancel() both
> return the connection to the pool (either hibernate's own pool if using
> DriverManager or the datasource connection pool if using a Datasource.)
> At present hibernates own connection pooling algorithm is suboptimal, I
> know, but it doesn't quite amount to "connection leakage". Certainly
> there should be no connection leakage if using a datasource.
>
> The only possiblity of connection leakage is if you fail to call either
> commit() or cancel() in a finally block.
>
> I think a big problem here is that commit() is a misleading name for
> something that
>
> 1. Always Flushes.
> 2. Sometimes closes the connection. (if using Datasource)
> 3. Sometimes commits the connection. (if using DriverManager or if
> using Datasource and hibernate.auto_commit=true)
>
> I'm open to better suggestions ( can always deprecate commit() ), but
> perhaps the solution lies in better documentation.
>
> I mean really this method has confusing semantics so I'm really open to
> alternatives.
>
> > in the situation where u supply a jdbc connection to hibernate, u can
> always
> > guarentee that the connection will be closed in a timely manner by
> calling
> > the close method on the connection inside a finally block.  however if u
> let
> > hibernate open a connection for u, there is no way u can do this.  i c
> that
> > RelationalDatabaseSession.java has a finalize method that cleans up the
> > connection (which is good), but there is no guarentee as to when the gc
> will
> > run, and therefore when the finalize method will be called.  perhaps a
> > session.close method is in order?
>
>
>