db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julius Stroffek (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2220) Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
Date Tue, 13 Feb 2007 17:51:06 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Julius Stroffek updated DERBY-2220:
-----------------------------------

    Attachment: d2220_beta2.diff

What about the second patch?

I changed the code to maintain the list of all uncommitted transactions and rollback all of
them. This should cover the whole problem not only the previous simple case.

The patch will forbid using the code like this one

            XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1526/TestDB",
"", "");
            XAResource xaResource = xaConnection.getXAResource();
            conn = xaConnection.getConnection();           
            XAConnection xaConnection2 = createXAConnection("jdbc:derby://localhost:1526/TestDB",
"", "");
            XAResource xaResource2 = xaConnection2.getXAResource();
            Xid xid = createXid(value);        
            xaResource.start(xid, XAResource.TMNOFLAGS);
            Statement statement = conn.createStatement();
            statement.execute(query);            
            xaResource.end(xid, XAResource.TMSUCCESS);
            
            // commiting a transaction on different resource
            xaResource2.prepare(xid);
            xaResource2.commit(xid, false);

It will force the user to commit or rollback the transaction on a same connection as it was
executed. I went through JTA API and have not found anything that will state that the JTA
implementation have to allow commit/rollback of a transaction on different connection than
the unit of work was executed on. At least the specification forbids resuming a suspended
transaction on different connection than it was started on. Then I think made also no sense
to require to commit or rollback the transaction on the different connection than the unit
of work was executed on.

There exists 1:1 mapping between XAConnection instance and XAResource instance. The XAResource
methods use the corresponding logical connection to pass commands to a database.

Please provide any further comments on this.

> Uncommitted transactions executed throught XAResource will held locks after the application
terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2220
>                 URL: https://issues.apache.org/jira/browse/DERBY-2220
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions: 10.3.0.0
>         Environment: Solaris Nevada build 49, Sun's JDK1.6
>            Reporter: Julius Stroffek
>         Assigned To: Julius Stroffek
>         Attachments: d2220_beta.diff, d2220_beta2.diff, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
>             String query = "insert into dummy (field1) values ('" + Integer.toString(value)
+ "')";
>             XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB",
"", "");
>             XAResource xaResource = xaConnection.getXAResource();
>             conn = xaConnection.getConnection();
>             
>             Xid xid = createXid(value);        
>             xaResource.setTransactionTimeout(10);
>             xaResource.start(xid, XAResource.TMNOFLAGS);
>             
>             Statement statement = conn.createStatement();
>             statement.execute(query);        
>             
>             // terminate the client application
>             // this will not release any locks
>             System.exit(0);

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message