You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <de...@db.apache.org> on 2006/02/18 01:16:40 UTC
[jira] Created: (DERBY-1004) Client should not require user to
rollback the active transaction before call to
PooledConnection.getConnection()
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/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();
--
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
[jira] Updated: (DERBY-1004) Client should not require user to
rollback the active transaction before call to
PooledConnection.getConnection()
Posted by "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 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();
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/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();
Two notes on this bug.
1) At the time of its filing checkDataSource did not yet fully run with client, but ran at least to the point that this bug can be reproduced.
2) Dan posted this quote from JDBC30 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 toforce 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 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
[jira] Commented: (DERBY-1004) Client should not require user to
rollback the active transaction before call to
PooledConnection.getConnection()
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1004?page=comments#action_12415237 ]
Deepa Remesh commented on DERBY-1004:
-------------------------------------
I went through the patch and it looks good to me. I also checked that the test passes with the patch and fails without it.
I have one minor comment which is just a readability issue. I am curious why you changed the place where rollback is called. In an earlier comment, you had mentioned you added a rollback to client.am.Connection.resetConnection. I thought this was better as it would keep all the changes to the physical connection at one place. Did it cause any problems? To match the method names to the actions, I think it would be good to have all changes to the physicalConnection in one method, something like resetPhysicalConnection. Then call createLogicalConnection to get the logical connection. This would be similar to what is being done in EmbedPooledConnection.getConnection.
> 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.2.0.0, 10.1.3.0, 10.1.2.2, 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
[jira] Commented: (DERBY-1004) Client should not require user to
rollback the active transaction before call to
PooledConnection.getConnection()
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1004?page=comments#action_12415028 ]
David Van Couvering commented on DERBY-1004:
--------------------------------------------
Never mind, I found XATest.java, a directory listing sort problem (capital XA goes ahead of lower case anything...)
> 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.2.0.0, 10.1.3.0, 10.1.2.2, 10.1.2.3
> Reporter: Kathey Marsden
> Assignee: David Van Couvering
> 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 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
[jira] Commented: (DERBY-1004) Client should not require user to
rollback the active transaction before call to
PooledConnection.getConnection()
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Commented: (DERBY-1004) Client should not require user to
rollback the active transaction before call to
PooledConnection.getConnection()
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1004?page=comments#action_12415027 ]
David Van Couvering commented on DERBY-1004:
--------------------------------------------
I put a rollback into client.am.Connection.resetConnection and commented out the needRollbackBeforePCGetConnection, and it seems to fix this problem. I can't find your XATest.java test, Dan, did you ever commit it? If not, maybe I'll add a separate test to one of the derbynet tests.
> 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.2.0.0, 10.1.3.0, 10.1.2.2, 10.1.2.3
> Reporter: Kathey Marsden
> Assignee: David Van Couvering
> 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 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
[jira] Updated: (DERBY-1004) Client should not require user to
rollback the active transaction before call to
PooledConnection.getConnection()
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1004?page=all ]
David Van Couvering updated DERBY-1004:
---------------------------------------
Attachment: DERBY-1004.diff
This patch should fix the problem. Posting for review. I am simultaneously running derbynetclientmats
> 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.2.0.0, 10.1.3.0, 10.1.2.2, 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
[jira] Updated: (DERBY-1004) Client should not require user to
rollback the active transaction before call to
PooledConnection.getConnection()
Posted by "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
[jira] Commented: (DERBY-1004) Client should not require user to
rollback the active transaction before call to
PooledConnection.getConnection()
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1004?page=comments#action_12366870 ]
Daniel John Debrunner commented on DERBY-1004:
----------------------------------------------
The same issue exists for the getConnection() on the XAConnection object for the client driver. I'm adding a new tets jdbcapi/XATest.java that will replace the xa*.sql tests. It has a comment with this bug number when it forces a commit or rollback to make the test run under client.
> 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
[jira] Closed: (DERBY-1004) Client should not require user to
rollback the active transaction before call to
PooledConnection.getConnection()
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1004?page=all ]
Kathey Marsden closed DERBY-1004:
---------------------------------
Fix verified by reenabling test
> 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.2.0.0, 10.1.3.0, 10.1.2.2, 10.1.2.3
> Reporter: Kathey Marsden
> Assignee: David Van Couvering
> Priority: Minor
> Fix For: 10.2.0.0, 10.1.3.0
> 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
[jira] Commented: (DERBY-1004) Client should not require user to
rollback the active transaction before call to
PooledConnection.getConnection()
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1004?page=comments#action_12415409 ]
Deepa Remesh commented on DERBY-1004:
-------------------------------------
Hi David, My comment was only based on your previous comment which made me wonder why you did not add the rollback to resetConnection itself. Thanks for explaining your findings. As I said before, the patch looks good and solves this issue.
> 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.2.0.0, 10.1.3.0, 10.1.2.2, 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
[jira] Assigned: (DERBY-1004) Client should not require user to
rollback the active transaction before call to
PooledConnection.getConnection()
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1004?page=all ]
David Van Couvering reassigned DERBY-1004:
------------------------------------------
Assign To: David Van Couvering
> 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.2.0.0, 10.1.3.0, 10.1.2.2, 10.1.2.3
> Reporter: Kathey Marsden
> Assignee: David Van Couvering
> 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 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
[jira] Resolved: (DERBY-1004) Client should not require user to
rollback the active transaction before call to
PooledConnection.getConnection()
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1004?page=all ]
David Van Couvering resolved DERBY-1004:
----------------------------------------
Fix Version: 10.2.0.0
10.1.3.0
Resolution: Fixed
Fixed in trunk, revision 412852. Fixed in 10.1 branch, revision 412860.
> 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.2.0.0, 10.1.3.0, 10.1.2.2, 10.1.2.3
> Reporter: Kathey Marsden
> Assignee: David Van Couvering
> Priority: Minor
> Fix For: 10.2.0.0, 10.1.3.0
> 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