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 Sun, 09 Jan 2005 00:16:27 GMT
Still another thought: Might be the best idea to store even locks into
the file system and not having them in memory. This way changes to the
file resource manager would be minimal. This would, however, require a
lock manager that saves to disk - not to difficult and certainly a
funny thing. Saving locks themselves should really be protected by 1.4
file locks as well...

Oliver


On Thu, 6 Jan 2005 23:34:09 +0100, Oliver Zeigermann
<oliver.zeigermann@gmail.com> wrote:
> 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