commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Zeigermann <oliver.zeigerm...@gmail.com>
Subject Re: [transaction] cluster
Date Thu, 06 Jan 2005 22:34:09 GMT
On Thu, 06 Jan 2005 17:21:44 -0500, Brant Boehmann
<brant.boehmann@newmail.cadre5.com> wrote:
> Single node is probably not an option because it would be a single point
> of failure. (I realize a shared disk is also a single point of failure,
> but in a somewhat different way as the shared disk I utilize resides on
> a large SAN with Fiber Channel Cards).

I see.
 
> Haven't checked the FileChannel class, and I'm only vaguely familiar
> with the NIO package, but I think the deadlock problem could be solved
> with a timeout on locks possibly in a "reaper" thread???

There is no timeout you could specify, but an additional thread that
closes the channel will cause an exception with the waiting thread
AFAIK. So, right, this should work. Of course this is no real deadlock
detection, but it should do...

> I don't quite understand the semantics of 2-phase commit, but is it even
> possible for the FileResourceManager to implement 2-phase commit?

It would. But I do not know how ;) But who cares, half of the popular
RDBMSs do not...

> I'm not an XA expert. What is the effect of a single commit operation
> embedded in an XA transaction?

Will work most of the time, the only thing that might happen (although
practically very rarely) is that some branches of the transaction are
committed and others are not. This will be the case when on of the
systems taking part in the XA transaction just can not commit and
others already have. The FileResourceManager is very robust against
permant commit failures, though...

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message