db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1004) Client should not require user to rollback the active transaction before call to PooledConnection.getConnection()
Date Thu, 08 Jun 2006 17:52:31 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1004?page=comments#action_12415389 ] 

David Van Couvering commented on DERBY-1004:
--------------------------------------------

Hi, Deepa, thanks for your review.  

The problem was I was still getting the error in some cases when I put it there.  getConnection(),
today, first calls createLogicalConnection().  This method calls closeWithoutRecyclingToPool(),
which throws an exception if there are transactions in progress.  I can't get rid of this
check because in some cases (e.g. when close() is called), this is a valid exception.

After calling createLogicalConnection(), ClientPooledConnection.getConnection() calls reset
on the physical connection.  Through a series of twisty passages this ends up calling Connection.resetPhysicalConnection(),
and then at the network layer everything is cleaned up without actually closing the socket,
and then calls Connection.completeReset(), which then calls a method completeLocalRollback()
(I just discovered this), which appears to do a client-side-only rollback and closes any open
cursors.

I suppose another way to solve this would be, in ClientPooledConnection.getConnectio() to
call physicalConnection_.reset() *first*, and then createLogicalConnection(), and at that
point the transactions would all be rolled back (accomplished by completeReset()).  But changing
the order to me seems somewhat risky, I am not sure I fully comprehend the client semantics
and am worried I"d potentially introduce strange regressions.

If you think this might actually be reasonable, I can go ahead and try this.  I'll probably
try it while I'm waiting to hear back from you :)

David

> 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
>     Assignee: David Van Couvering
>     Priority: Minor
>  Attachments: DERBY-1004.diff
>
> 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 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();

-- 
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