db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: svn commit: r378532 - in /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests: master/DerbyNetClient/checkDataSource30.out suites/DerbyNetClient.exclude tests/jdbcapi/checkDataSource.java tests/jdbcapi/checkDataSource30.java
Date Fri, 17 Feb 2006 18:48:54 GMT
Daniel John Debrunner wrote:

> kmarsden@apache.org wrote:

>> - Changed to perform an explicit rollback of active transactions for client before
performing a PooledConnection.getConnection()
>>  I think this is an issue with embedded that it allows a PooledConnection.getConnection()
with an active transaction, instead of throwing an error if the transaction is active.
> 
> 
> I'm not sure this is a correct change, I thought it was defined that
> PooledConnection.getConnection() closed the existing connection. I need
> to find that reference.

Found the reference through comments in the Derby code for a method
called from EmbedPooledConnection.getConnection(), that was nice!

JDBC 3.0 section 11.4

A single physical PooledConnection object may generate many logical
Connection objects during its lifetime. For a given PooledConnection object,
only the most recently produced logical Connection object will be valid. Any
previously existing Connection object is automatically closed when the
associated
PooledConnection.getConnection method is called. Listeners (connection
pool managers) are not notified in this case.
This gives the application server a way to take a connection away from a
client.
This is an unlikely scenario but may be useful if the application server
is trying to
force an orderly shutdown.

So embedded is correct, I think this part of the test change should be
reverted.

Dan.


Mime
View raw message