Re: closing statements when connection is closed

Oliver,

I agree. ISTM that the suggestion for automatically closing all
statements is to free up any server side resource that an open statement
might require. Since we in general don't hold any server side resources
that exist outside the connection that rational wouldn't apply to our
implementation. So the only thing left to be gained is potentially some
memory savings, but as you point out we can only reduce the memory not
eliminate it since by definition this is only a problem if the
application still is referencing the statement objects.

--Barry

Oliver Jowett wrote:

> Dave Cramer wrote:
>
>> 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.
>
>
> Sure. It just seems like a fair amount of work to support a case where
> we will leak memory regardless of what the driver does. The client is
> keeping the Statement/ResultSet alive, there's nothing the driver can do
> to cause GC of that object, at best all we can do is reduce the
> footprint of the leaked objects. Is doing this worth the extra
> complexity in the driver? It doesn't look like a common error to me..
>
>> On Mon, 2004-02-09 at 23:33, Oliver Jowett wrote:
>>
>>> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings