You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Sandip Ghayal (JIRA)" <de...@geronimo.apache.org> on 2005/01/25 18:02:17 UTC
[jira] Created: (GERONIMO-550) Functioning of Transaction Time out was not properly handled
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
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
[jira] Commented: (GERONIMO-550) Functioning of Transaction Time out was not properly handled
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-550?page=comments#action_58192 ]
David Jencks commented on GERONIMO-550:
---------------------------------------
I've applied the changes that remove the timer/interrupt and just check the time at commit, and also I reset the thread timeout value after it has been used. I added the test.
I did not convert the internal time unit to seconds.
I kept the use of the ExtendedTransactionManager interface to start a transaction while specifying a timeout to avoid unnecessary use of a thread local.
I'd still like to investigate whether we can write a thread-safe timer/interrupt timeout mechanism, but perhaps it should be an alternative to this one.
Revision 128441
> 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
[jira] Updated: (GERONIMO-550) Functioning of Transaction Time out was not properly handled
Posted by "Sandip Ghayal (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-550?page=history ]
Sandip Ghayal updated GERONIMO-550:
-----------------------------------
Attachment: TransactionTimer.java
patches.out
1> Removal of timer event for Transaction Timeout,
Instead use current time before doing commit of
transaction to figure out if rollback is needed
Reason for change: Handling of timer event would be
very complicated and would require synchronization on
other methods like commit and rollback for proper
functionality
2> Changing time out value from milliseconds to
seconds: I have made the unit of time measurement for
time out to seconds instead of previous practice of
milliseconds. Added the class for getting the current
time in seconds.
Reason for change: Transaction time out does not need
to be so accurate. All the locations of input always
gave time in seoconds. New class was added for
efficiency.
3> Using standard begin interface, instead of modified
one: I have modified code to use standard interface
for begin
Reason for Change: Ease of use by staying with
standards ??
4> Timeout logic modification: Added the facility to
reset the transaction timeout back to default value
after the transaction is started.
Reason for change: This is a debatable issue. And
specifications don't specify anything on this. My
stand on this is once the timeout value is set then
next transaction starting on this thread would use
this timeout value and subsequent transactions should
start using the default values. If we don't do this
then there are cases where user could get unexpected
transaction timeout values. E.g. (a) EJB1 supplied
by Vendor 1 sets Transaction Timeout and Calls EJB2
supplied by Vendor 2. EJB 2 requires to be executed
under default timeout but EJB 2 does not know that
EJB1 has changed transaction timeout. E.g. (b)
Extending e.g. (a), EJB 2 sets transaction timeout
executes transaction, and then control returns back
to EJB1. EJB 1 is not aware that EJB2 has changed
transaction timeout. so next transaction started by
EJB1 will be under transaction timeout of EJB2.
5> Added test cases for testing timeout: Added a
single test case to test two conditions. One the
timeout condition and other to test the recovery from
timeout.
> 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
> 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
Re: [jira] Commented: (GERONIMO-550) Functioning of Transaction Time out was not properly handled
Posted by Sandip Ghayal <sg...@yahoo.com>.
Refer to SG>> Below
Cheers,
Sandip
--- "David Jencks (JIRA)" <de...@geronimo.apache.org>
wrote:
> [
>
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.
SG>> I don't have any strong views on the either side,
Its just that we have to go thru extra layer. But sure
I will leave it up to you to make that decision.
>
> (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.
SG>> How about we do this leave it to seconds for now,
also the new class that I have provided ensures that
getting current time is efficient. So leave this fix
and we can revisit this after certification ? May be
create a Jira and attack it later.
>
> (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.
SG>> Lets go with non-interrupting approach for now as
interrupting approach is not very reliable to my
understanding. And JVM does not ensure that proper
exceptions etc are propogated when thread is
interrupted. A badly written code could actually end
up ignoring the I/O interrupts. Also from my
observation of remote failures usually the
communication will be borken on remote system failure,
and driver should send back appropriate response (or
exception) back. Only time this fails is when there is
some kind of dead lock happening on the remote side.
Low probability and when this happens entire system
will have bigger issues then a single transaction
failing. Again here we can create an issue in JIRA and
attack it 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
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[jira] Commented: (GERONIMO-550) Functioning of Transaction Time out was not properly handled
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ 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
[jira] Assigned: (GERONIMO-550) Functioning of Transaction Time out was not properly handled
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-550?page=history ]
David Jencks reassigned GERONIMO-550:
-------------------------------------
Assign To: David Jencks
> 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
[jira] Closed: (GERONIMO-550) Functioning of Transaction Time out was not properly handled
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-550?page=all ]
David Jencks closed GERONIMO-550:
---------------------------------
Resolution: Fixed
Fix Version: 1.0-M4
Current (fixed) implementation seems to work and I haven't had any comments back from Sandip.
> Functioning of Transaction Time out was not properly handled
> ------------------------------------------------------------
>
> Key: GERONIMO-550
> URL: http://issues.apache.org/jira/browse/GERONIMO-550
> Project: Geronimo
> Type: Bug
> Components: transaction manager
> Versions: 1.0-M4
> Environment: All platforms and All JDK Version
> Reporter: Sandip Ghayal
> Assignee: David Jencks
> Fix For: 1.0-M4
> 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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira