db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepa Remesh (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1025) [xa] client XAResource.start() does not commit an active local transaction when auto commit is true
Date Fri, 14 Apr 2006 14:24:01 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1025?page=all ]

Deepa Remesh updated DERBY-1025:

    Attachment: derby-1025-patch1-v1.diff

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

* 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

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. 

* 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
        // 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,
> 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

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message