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-2432) Unimplemented transaction time out for XA transactions may cause that locks will not be released when client terminates outside a unit of work.
Date Wed, 13 Jun 2007 14:24:26 GMT

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

Julius Stroffek commented on DERBY-2432:

> Is it specified anywhere what the transaction timeout means? I found a 
> description in the javadoc for XAResource.setTransactionTimeout(), but 
> it doesn't say anything about the effect of the timeout.

No, there is no exact specification what timeout means.

> The property is called derby.jdbc.xaTransactionTimeout. Is it related 
> to JDBC, or should we call it something else, like 
> derby.xa.transactionTimeout?

Yes, it is the 'default value' about which the javadoc
of XAResource.setTransactionTimeout is talking about.
And it's from JDBC specification. 

> I'm not sure I quite understand what the test does. For instance, it's 
> not clear to me which statements/transactions should time out and what 
> makes them time out. Also, would it be possible to split the test into 
> smaller/simpler test cases, like (a) set transaction timeout, (b) 
> start transaction, (c) sleep for a while, (d) check that the 
> transaction was aborted?

Yes, that would be possible. Currently, 1000 global transactions
are performed during the test. Everyone of them just inserts a row
into XATT table. The rows inserted by the transactions are different.
Some of these transactions are committed and some of them are
left in different stages. After finishing these 1000 transactions a select
statement is executed on that table. However, if there are still some
unfinished transactions that were not aborted they will hold a lock
on a XATT table until they will get rolled back by the transaction timeout.
The number of rows in the XATT table is calculated. It is then compared
with the excepted number of rows (the trnsaction we know we have

The call
before calling xaRes.start() makes the transactions to get timed out.

Is this understandable? Would it be ok to explain this more in comments?

> I'm also not sure I understand the following code 
> + } else { 
> + // check the timout for associated transactions 
> + ; 
> + } 
> It says it checks the timeout, but it doesn't do anything.

The time out is setted up for the transaction at the beggining
of the transaction. Different transactions are left in different
states as the timeout task will try to roll back transactions
in different state / connection association, etc. The code
actually does not test the timeout for associated transactions
directly, it just left the transaction in a state it is (and it is
associated with the connection).

> In this try/catch in the test, shouldn't there have been a call to 
> fail() after xaRes.end()? 
> + try { 
> + xaRes.end(xid, XAResource.TMFAIL); 
> + } catch (XAException ex) { 
> + if (ex.errorCode < XAException.XA_RBBASE 
> + || ex.errorCode > XAException.XA_RBEND) 
> + { 
> + throw ex; 
> + } 
> + }

Might be, it will then test something more than just a timeout feature.

> In the test, the variables xaConn, xaRes and conn are declared and 
> initialized right before the for loop, but also at the beginning of 
> the body of the for loop, so their initial values are always thrown 
> away. Could the variable declarations be moved inside the for loop 
> instead?

Yes, i missed that.

> Unimplemented transaction time out for XA transactions may cause that locks will not
be released when client terminates outside a unit of work.
> -----------------------------------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-2432
>                 URL: https://issues.apache.org/jira/browse/DERBY-2432
>             Project: Derby
>          Issue Type: New Feature
>          Components: JDBC
>            Reporter: Julius Stroffek
>            Assignee: Julius Stroffek
>             Fix For:
>         Attachments: d2432.diff, d2432.stat, d2432_v2.diff, d2432_v2.stat, description.txt
> The XAResource interface provides function setTransactionTimeout which is currently not
supported in derby.
> When client application uses client driver to connect to derby database and the application
crashes outside the unit of work of XA transaction and the transaction is not committed or
rolled back yet the locks held by the transaction will not be released.

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

View raw message