Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <15543123.1181815166542.JavaMail.jira@brutus>
Date: Thu, 14 Jun 2007 02:59:26 -0700 (PDT)
From: "Julius Stroffek (JIRA)" <jira@apache.org>
To: derby-dev@db.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.
In-Reply-To: <20978358.1173456609289.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Julius Stroffek commented on DERBY-2432:
----------------------------------------

I wanted to solve the similiar problem like DERBY-2220 solved
but also for the case where the global transaction is not associated
with any connection. In that case without a timeout that global
transaction may held locks forever. I do not know what is
the purpose of timeout in jdbc specification (it is not explained)
but I see the purpose in just not to held resource for a long time.

> If so, is the code that cancels the running statement necessary?

What else could we do in this case? The transaction times out so
I thing the best way is to cancell everything. If there is a running
statement and we will not cancel it, so shell we schedule a new
timeout task later? Or just ignore this transaction? I think that
doing something else would lead to not quite transparent behaviour.

The behaviour you are proposing is also acceptable.

> To avoid cases like: transaction manager calls prepare(), the XAResource 
> votes OK, and half a second later the XAResource aborts because the 
> transaction took too long.)

This might be handled by cancelling a timeout task also in prepare method.
After the application calls prepare, RM is allowed to heuristically commit
or rollback the transaction. This means that it will no longer hold any resources.
I do not know quite well how the heuristicall commit/rollback works. I'll explore
this.

About other DBs:
---
IBM JDBC Universal Driver - feature not implemented.
PostgreSQL - feature not implemented.
MySQL - feature not implemented.
Oracle - I do not know. I have no Oracle installed.


> 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: 10.3.0.0
>
>         Attachments: d2432.diff, d2432.stat, d2432_v2.diff, d2432_v2.stat, d2432_v3.diff, d2432_v3.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.