geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <...@geronimo.apache.org>
Subject [jira] Commented: (GERONIMO-550) Functioning of Transaction Time out was not properly handled
Date Thu, 27 Jan 2005 18:35:17 GMT
     [ http://issues.apache.org/jira/browse/GERONIMO-550?page=comments#action_58176 ]
     
David Jencks commented on GERONIMO-550:
---------------------------------------

First of all, thank you for pointing out that the current transaction timeout implementation
is not thread safe: I agree.

(4)  After thinking about this issue, I agree that we should set the thread tx timeout back
to default after each transaction.  Anyone who is changing the tx timeout should set it for
each transaction to be sure they are getting the value they want, so resetting it will avoid
surprises.

(3) I would prefer to keep the extended interface because it avoids use of a thread local.
Reviewing the current usage of the extended interface I notice that it doesn't make a lot
of sense. However, I expect we will provide a way to specify the timeout for a container managed
transaction which will be a more sensible use of the interface.

(2) I think the change to seconds rather than milliseconds depends on resolving (1).  If we
are interrupting threads, then I think it is possible that fractional second timeout resolution
could be useful in certain specialized situations.  If we do not interrupt threads then the
finer resolution makes no sense.

(5) Thanks for the test case :-)

(1) This is clearly the most important part of the proposal.  Waiting until commit is called
and checking the time is clearly a simpler, easier to understand, easier to implement, and
spec compliant implementation.  It will also avoid possible bad side effects from badly written
drivers.  However, I'm reluctant to adopt only this implementation without more research.

My understanding of the fundamental purpose of transaction timeouts is that they are a crude
way to detect remote failures that could not be detected otherwise.  (JINI leases provide
a considerably more sophisticated and transparent technique.)  I think timeouts are designed
to protect not against "it took 2 minutes rather than 1  minute" but "it crashed and will
never return".  As such, timing out should let the server clean up the resources used by the
transaction, even though some remote calls have not returned.  In pre-jdk 1.4 times, there
was no way to do this, since IO was not interruptible.  However in jdk 1.4 at least some IO
and potentially all IO is interruptable, so interrupting a thread should allow the driver
to realize there is a problem and signal a fatal error resulting in the connection getting
destroyed.

On the other hand, it is entirely possible that a badly written driver could leave a connection
in an inconsistent and unusable state after being interrupted, without signalling an error.
 If actual popular commercial drivers do this, we should definitely provide a non-interrupting
timeout implementation choice.  Do you know to what extent this is the case?  If most drivers
do this, perhaps we should implement the non-interrupting approach now and work more on the
interrupting approach after certification.

> Functioning of Transaction Time out was not properly handled
> ------------------------------------------------------------
>
>          Key: GERONIMO-550
>          URL: http://issues.apache.org/jira/browse/GERONIMO-550
>      Project: Apache Geronimo
>         Type: Bug
>   Components: transaction manager
>     Versions: 1.0-M4
>  Environment: All platforms and All JDK Version
>     Reporter: Sandip Ghayal
>     Assignee: David Jencks
>  Attachments: TransactionTimer.java, patches.out
>
> Currently operation for timeout for transaction is not thread safe

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message