Thanks, Dan et al.
StatementFinalizer is exactly what I was looking for.  A quick look at
the source
code<http://javasourcecode.org/html/open-source/tomcat/tomcat-7.0.29/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java.html>
reveals
exactly what I needed to know: statements are stashed away and individually
closed on Connection.close().
-Igor.


On Wed, Apr 10, 2013 at 1:26 PM, Bertrand Guay-Paquet <
ber...@step.polymtl.ca> wrote:

> Hi,
>
> Have a look at 
> http://markmail.org/thread/**iqgvj34347z77tnc<http://markmail.org/thread/iqgvj34347z77tnc>for
>  a bug in the current Tomcat version and its workaround. This seems to
> affect MySQL primarily.
>
> Regards,
> Bertrand
>
>
> On 10/04/2013 4:05 PM, Igor Urisman wrote:
>
>> Hello,
>>
>> The new Tomcat 7 JDBC
>> pool<http://people.apache.org/**~fhanik/jdbc-pool/jdbc-pool.**html<http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html>
>> >is
>>
>> quite new and not much has been written on it yet.  Has anyone looked
>> it
>> how well it manages underlying resources, both in java domain and in the
>> database?
>>
>> More specifically, what happens when I call Connection.close()
>> without explicitly first closing statements and result sets that were
>> created via this connection? An un-pooled raw JDBC connection will do the
>> right thing and close underlying resource when closed.  But in a pool
>> setup, connection close() simply returns it to the pool.
>>
>> In an ideal world, a pooled connection proxy will keep track of the
>> underlying resources and release/close them when closed.  But that's known
>> not to have been the case in the past and I didn't find any guarantees of
>> that in the docs for the new pool.  I've been running some tests and I am
>> coming up with surprises.  I don't want yet to post code to this list.
>>   Just a general inquiry for now.
>>
>> Thanks in advance,
>> -Igor.
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: 
> users-unsubscribe@tomcat.**apache.org<users-unsubscr...@tomcat.apache.org>
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Reply via email to