[jira] Updated: (DERBY-1004) Client should not require user to rollback the active transaction before call to PooledConnection.getConnection()

["Kathey Marsden (JIRA)" <de...@db.apache.org>]

     [ 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