db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1004) Client should not require user to rollback the active transaction before call to PooledConnection.getConnection()
Date Sat, 18 Feb 2006 00:33:07 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1004?page=all ]

Kathey Marsden updated DERBY-1004:
----------------------------------

    Description: 
For a PooledConnection.getConnection() the connection gets closed.
 Embedded automatically rolls back any activity on the connection.
 Client requires the user to rollback and gives an SQLException  
 java.sql.Connection.close() requested while a transaction is in progress

The test jdbcapi/checkDataSource.java shows this bug.   A boolean needRollbackBeforePCGetConnection
has been added to the test and  explicit rollback has been added to the test to help get this
test  running  with client.  

To reproduce take out instances of the explicit rollback for client from the test e.g.

if (needRollbackBeforePCGetConnection)
			c1.rollback();




  was:
For a PooledConnection.getConnection() the connection gets closed.
 Embedded automatically rolls back any activity on the connection.
 Client requires the user to rollback and gives an SQLException  
 java.sql.Connection.close() requested while a transaction is in progress

The test jdbcapi/checkDataSource30.java shows this bug.   A boolean needRoolbackBeforePCGetConnection
has been added to the test and  explicit rollback has been added to the test to get it to
run with client.

To reproduce take out instances of the explicit rollback for client from the test e.g.

if (needRollbackBeforePCGetConnection)
			c1.rollback();





Two notes on this.  
1)
The test does not yet fully run at the time this bug was filed, but this issue was discovered
in the process.
2)
Dan posted this from the spec
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.



> Client should not require user to rollback the active transaction before call to PooledConnection.getConnection()
> -----------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1004
>          URL: http://issues.apache.org/jira/browse/DERBY-1004
>      Project: Derby
>         Type: Bug
>   Components: Network Client
>     Versions: 10.1.2.2, 10.2.0.0, 10.1.3.0, 10.1.2.3
>     Reporter: Kathey Marsden
>     Priority: Minor

>
> For a PooledConnection.getConnection() the connection gets closed.
>  Embedded automatically rolls back any activity on the connection.
>  Client requires the user to rollback and gives an SQLException  
>  java.sql.Connection.close() requested while a transaction is in progress
> The test jdbcapi/checkDataSource.java shows this bug.   A boolean needRollbackBeforePCGetConnection
has been added to the test and  explicit rollback has been added to the test to help get this
test  running  with client.  
> To reproduce take out instances of the explicit rollback for client from the test e.g.
> if (needRollbackBeforePCGetConnection)
> 			c1.rollback();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message