RE: Re: Fix for Bug #555

["Abdul Salam, Sajida (Cognizant)" <Sa...@cognizant.com>]

Thanks for your reply.

As to your queries: "How do you determine if the connector is interruptible?"
We found out that from jdk 1.4 onwards the NIO (NewIO) package was introduced, which supported interruptible IO. So, if the driver used supports NIO then it can be interrupted in case of a remote failure, thus closing the transaction, rather than waiting for a timeout to happen. And as of now only the mysql driver supports that. Hence, presently, all the drivers which can be interrupted have been statically listed and any driver which in future might support NIO can be added to the list.

"What advantage does this combined approach offer over always using a timer?"

We started by reviewing the timer based implementation present prior to reivision 128441 for synchronization issues and made valid changes. We then determined that only if the driver was interruptible it would make any sense to use a timer based timeout. If the connector wasn't interruptible (didn't use NIO) even if the timeout occured it wouldn't have an effect on the driver. However in case of NIO drivers a timeout on such a thread will actually interrupt the thread, thus closing the channel, which should be the case in network/remote failures. Hence we kept on the previous implementation for non-interruptible drivers and added the new piece for interruptible drivers.


-------- Forwarded Message --------
From: David Jencks <david_jencks@yahoo.com <mailto:David%20Jencks%20%3cdavid_jencks@yahoo.com%3e> >
Reply-To: dev@geronimo.apache.org
To: dev@geronimo.apache.org
Subject: Re: FW:
Date: Mon, 21 Nov 2005 13:43:58 -0800


On Nov 21, 2005, at 3:57 AM, Abdul Salam, Sajida ((Cognizant)) wrote:

>
> Hi,
>     Me and my colleagues are working on a fix for Bug #555. Currently
> we have implemented a hybrid transaction code such that based on
> whether the database driver being used is interruptible or not, a
> timer based transaction timeout or a timeout based on the current time
> is used. This implementation is still in a raw state and we need to
> test this further. Please send me your views on this implementation.

That's an interesting idea!  How do you determine if the connector is
interruptible?  What advantage does this combined approach offer over
always using a timer?  I had thought that the main technical difficulty
with a timer based approach was to assure that there was enough
synchronization around the transaction status so that it would actually
work reliably, without introducing excess synchronization that would
slow down speedy transaction unnecessarily.  Have you carefully
reviewed your code for synchronization?  In any case I'm very glad to
see more people looking at this code!

There are some additional problems we encountered with a timer based
approach that we have not yet resolved satisfactorily with Sun.  Either
we have not been able to convey our views successfully or the Sun spec
committee believes a timer/interrupt based approach is not consistent
with the spec.  I have not been able to find any support for what
appears to be Sun's position on this in either the jta or xa specs.

thanks,
david jencks

>
>  Thanks in advance,
>
>  Sajida Abdul Salam



This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly
prohibited and may be unlawful.

  Visit us at http://www.cognizant.com