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, 22 Feb 2007 17:51:05 GMT

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

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

>From the XA Transaction Specification from the OpenGroup:
---
It is an error, [XAER_PROTO], for a transaction manager to call xa_close () within a
thread of control that is associated with a transaction branch (that is, the transaction
manager must call xa_end() before calling xa_close ()).
---

So a change proposed in a patch is against this spec. It should be possible to close a xa
network connection on the trunk but not the ebedded one. To implement this according a spec
should be:
1.) undo any changes made to embedded connection
2.) check in the network client code (ClientXAConnection) when closing a connection to a database
whether it is already associated with the global transaction. If so, do not allow a connection
to be closed.

However, from my point of view it would be clearer to allow a connection to be closed and
rollback the associated transactions. I do not know whether it would be possible to even make
the behavior against the spec in some cases but I would like to discuss the difference.

I would expect that a transaction manager or an application would call the XAConnection.close
when it is associated with a transaction only in a exceptional case when it 'does not know
what else to do'. This could happen after throwing an unpredictable exceptions which do not
have to be handled - like NullPointerException. The handling of such an exception usually
propagates through couple of functions in the call stack. Usually, in this case the application
do not have to know the valid xid of the transaction or it do not have to know even whether
the xa connection is associated with the transaction or not. What the application should do?

1.) If it uses a transaction manager, the xid is stored in a transaction manager and if it
has a reference to transaction manager it can do some work with the transaction - probably
roll back

2.) If it uses XAResource and XAConnection directly, it may happen that the application will
loose xid and not the XAResource or XAConnection references (these might be shared across
the application). What to do in this case?

I am trying to think of an application with not the optimal design. This leads me what happens
if all the objects would be garbage collected? ;-)

---
Now I think that the best approach is to implement XAConnection.close according the specs
and to provide the cleanup with rollback of transactions in XAConnectionImpls.finalize methods
(as it is implemented now in close methods of the patch). I checked the code for this fastly
and it looks like it is not handled this way. I'll check this in more detail and I'll create
a new jira issue to address this separately.


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