commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [DBCP] Please let us start to improve the connection pool
Date Mon, 24 Mar 2003 20:50:50 GMT

On Mon, 24 Mar 2003, Mario Ivankovits wrote:

> Date: Mon, 24 Mar 2003 19:57:24 +0100
> From: Mario Ivankovits <>
> Reply-To: Jakarta Commons Developers List <>
> To: Jakarta Commons Developers List <>
> Subject: Re: [DBCP] Please let us start to improve the connection pool
> 1) ThreadLocal
> This might not help anything, or do i oversee something?
> Thread A gets a connection from the pool
> Thread A loops until the abandoned connection interval is passed
> The connection will be passed back to the pool.
> Thread B gets a connection from the pool (the connection which was passed
> back automatically by some pool mechanism)
> Thread B starts a transaction
> Thread A wakes up from sleep and call "commit()"
> Thread B roll back transaction
> Well, Thread A and B do always have their own TheadLocal and so, the Thread
> do not "know", that the connection is abandoned.
> 2) Proxy
> Your proxy looks much more interesting, but i think, it does also not
> correctly handle the problem described above. The proxy do not "change" the
> thread, only the connection does. For sure, i do not have much experiences
> with the java "Proxy" thinggy, but why should
>     if(  owner.get() == Thread.currentThread()  )
> ever by "not true", the thread is still alive.
> But maybe we could catch the method "passivate" and set the "connection" to
> null, now the connection is really released.
> I have to try this.
> I my case, i can easy implement such method. We have only one central place
> where we ge a connection from the pool, but i suggest this might not be
> correct for all sort of application out there. Such an application then has
> problems to decorate the connection instance.
> At least, i do not understand why this should be more elegant, if it works
> EVERY application has to read the docs, and implement this. This is like
> "cut and paste" in an OO design, isnt it?

IMHO, any application that depends on the connection pool for recovering
abandoned connections (whether or not it recycles them) is broken.  Far
better is to focus your energy on avoiding all the cases where you grab a
connection from the pool but fail to return it for some reason.

One simple way to do this is to encapsulate your JDBC-using code in a
try/catch/finally block, something like this:

  DataSource ds = ... get a reference to your pool ...;
  Connection conn = null;
  try {
    conn = ds.getConnection();
    ... do whatever you need to use this connection for ...
    ... including passing it as a parameter to methods  ...
    ... if they need access to the database             ...
  } catch (SQLException e) {
    ... deal with the exception appropriately ...
  } finally {
    if (conn != null) {
      try {
        conn.close();  // Returns connection to the pool
      } catch (SQLException e) {
        ... log a "it cannot happen, but it did" error ...

Note that the "finally" block is *always* executed, no matter what happens
inside, and no matter what exceptions might get thrown.  The same general
design pattern is useful for any requirement to allocate a scarce resource
and then make sure that it is freed when you are done.

If you do this consistently, you won't ever have to worry about
connections getting abandoned, and therefore won't need to worry about how
DBCP, or any other connection pool, deals with abandoned connections.

> Mario


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message