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] Commented: (DERBY-2220) Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
Date Thu, 08 Mar 2007 20:44:24 GMT

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

Julius Stroffek commented on DERBY-2220:
----------------------------------------

Knut, sorry I forgot to explain your important comment:

> It seems to me the patch correctly implements what you have described. I'm a little confused
after reading the discussion.
> Was there ever consensus that the described approach was correct? It does sound correct
to me, but I haven't studied
> all the different standards mentioned.

In Derbby XAConnection and XAResource instances are mapped 1:1. The methods of XAResource
instance in network driver use the XAConnection instance to send all the DRDA commands throught
the socket. Thus if the socket will be closed when the transaction is associated with the
connection, there is no way how to continue the work on that transaction. You can not join
that transaction, you can not end the association of that transaction, you can not rollback
nor commit the transaction. The locks held by the transaction will not be released. This is
not covered by the any of these specs and the proposed behavior can be only done because of
the way how derby implements the spec - it uses the same socket for both - XAConnection and
XAResource.

If derby would use a different socket for the XAResource object than the XAConnection, this
would not be possible because if the connection would be closed you could still end the association
of the transaction with the resource, but this is not possible in derby.

I think all these facts are mentioned in the discussion but there is no summary explaining
it.



> 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, d2220_try1.diff, d2220_try1.stat,
d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat,
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