Skip site navigation (1) Skip section navigation (2)

Re: closing statements when connection is closed

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: closing statements when connection is closed
Date: 2004-02-10 12:25:15
Message-ID: 1076415914.16154.151.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-jdbc
I don't see an issue in requiring jdk 1.2, we discussed deprecation of
1.1 support anyway.

I didn't envision using the weak references mechanism, but that seems
like a good solution.

In the JDBC API Tutorial and Reference, it suggests that driver
implementors assume the worst, so I think that we should attempt to
clean up our clients connections as best we can.

Dave
On Mon, 2004-02-09 at 23:33, Oliver Jowett wrote:
> Dave Cramer wrote:
> > It would appear from the documentation that we are supposed to clean up
> > JDBC resources when Connecton.close is called, would this include
> > statements. We currently don't track them or clean them up?
> > 
> > Opinions ?
> 
> We'd need JDK 1.2 to do this properly (weak reference support) otherwise 
> we end up keeping Statements that have not been closed alive as long as 
> the Connection object is.
> 
> As far as I can see the only additional thing we'd be able to clean up 
> is clearing the reference to row data held by open ResultSet objects. 
> This is only going to have an effect if something outside the driver is 
> holding references to the ResultSet or Statement after closing the 
> connection -- which seems like an application bug to me.
> 
> -O
> 
-- 
Dave Cramer
519 939 0336
ICQ # 14675561


In response to

Responses

pgsql-jdbc by date

Next:From: Dave CramerDate: 2004-02-10 12:50:10
Subject: Re: Pl/Java 1.0.0.b now avaiable on Linux 386 and Cygwin
Previous:From: IainDate: 2004-02-10 07:58:54
Subject: Re: closing statements when connection is closed

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group