[ http://issues.apache.org/jira/browse/DERBY-1025?page=all ]
Deepa Remesh updated DERBY-1025:
--------------------------------
Attachment: derby-1025-patch1-v1.diff
derby-1025-patch1-v1.status
Thanks Dan and Kathey for replying to my questions. I am attaching a patch
'derby-1025-patch1-v1.diff' which makes client's XAResource.start() to commit a
local transaction when auto commit is true.
------------------------------------------------
Summary:
------------------------------------------------
* Modifies NetXAResource.start to check if the connection is in autocommit mode
and flow an auto commit.
* Uncomments the tests for this issue in jdbcapi/XATest.java and
jdbcapi/checkDataSource.java
------------------------------------------------
Test:
------------------------------------------------
With this patch, I ran derbynetclientmats using Sun JDK1.4.2 on Windows XP. I
also ran checkDataSource test in client framework by temporarily removing it
from the exclude file.
------------------------------------------------
Questions:
------------------------------------------------
* When working on this issue, I saw this piece of code in client's
Connection.flowCommit method:
// Per JDBC specification (see javadoc for Connection.commit()):
// "This method should be used only when auto-commit mode has been
disabled."
// However, some applications do this anyway, it is harmless, so
// if they ask to commit, we could go ahead and flow a commit.
// But note that rollback() is less harmless, rollback() shouldn't be
used in auto-commit mode.
// This behavior is subject to further review.
// if (!this.inUnitOfWork)
// return;
// We won't try to be "too smart", if the user requests a commit, we'll
flow a commit,
// regardless of whether or not we're in a unit of work or in
auto-commit mode.
//
I saw that Kathey's trial patch was trying to check if we are in unit of work
before calling flowAutoCommit. On looking at the flowAutoCommit method, I saw
that this logic was planned to be in the commit method itself but currently it
is commented out mentioning "further review". Should I open a JIRA issue for
this so that we can pursue this later?
* I think the test for derby-1025 in checkDataSource.java is wrongly testing
XAER_DUPID because the second transaction uses the same xid. I think we want to
test that we cannot start a global transaction when the resource manager is
doing some work outside. I have changed the test to use a different xid. And
now the test gives me XAER_OUTSIDE,which I think is what we want to test. If
I'm wrong here, please let me know. I'll submit a separate patch for this.
> [xa] client XAResource.start() does not commit an active local transaction
> when auto commit is true
> ---------------------------------------------------------------------------------------------------
>
> Key: DERBY-1025
> URL: http://issues.apache.org/jira/browse/DERBY-1025
> Project: Derby
> Type: Bug
> Components: Network Client
> Reporter: Daniel John Debrunner
> Assignee: Deepa Remesh
> Attachments: derby-1025-draft1.diff, derby-1025-draft1.status,
> derby-1025-patch1-v1.diff, derby-1025-patch1-v1.status
>
> Embedded XAResource.start() implementation commits the active local
> transaction on the Connection associated with the XAResource if the
> connection is auto-commit mode.
> Client incorrectly throws an XAException with the XAER_RMFAIL error code (see
> DERBY-1024)
> XATest contains a work-around for client (calling commit) with a comment with
> this bug number.
--
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
