Re: Closing a database connection stored in a threadlocal upond death of thread

From:

Lew <lew@lewscanon.nospam>

Newsgroups:

comp.lang.java.programmer

Date:

Fri, 15 Jun 2007 19:26:26 -0400

Message-ID:

<7vadnUizl-a_ve7bnZ2dnUVZ_hmtnZ2d@comcast.com>

Hoss Spence wrote:

That is what I landed up doing but not happy with it. Picture this...
a logging infrastructure that logs to the db on a per thread basis
e.g. Eclipse rich client spawns a new job/thread and a static

Static bad. Instance good.

ThreadLocal keeps the database connection. Many different Eclipse rich
clients invoke this logging code. So have to hunt down all the places
threads are spawned.

No, have each Thread handle its own resources. Why hunt when the thing will
do it for itself?

Would be much easier if I could catch an arbitrary thread on it's [sic] deaththrows and close the dbconnection stored
in the ThreadLocal.

Sure, that's what you do. You just don't use finalize() for that.

Make it the finally{} of the inner workings of the run(), for example.

<incomplete>
public void run()
{
   Connection cxn = obtain();
   try
   {
     while ( ! atomicStop ) // look, I'm just avoiding a side discussion
     {
       serviceTheDbConnection( cxn );
     }
   }
   finally
   {
    try{ cxn.close } catch (SQLException e) { logger.warn( exc ); }
   }
}
</incomplete>

Now, the next question is why do you hold on to connections for the life of a
thread instead of the life of a transaction? You're going to have scalability
problems there.

--
Lew