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

[Gavin_King/Cirrus%<CI...@ci...>]

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?