You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Brant Boehmann <br...@newmail.cadre5.com> on 2005/01/06 19:32:08 UTC
[transaction] cluster
I am in a situation where we have a cluster of app servers.
A requirement has arrived where writing/updating/deleting multiple
files on a file system must occur atomically.
The disk is NFS mounted across all nodes in the cluster. Each node needs
to be able to write to disk in order to achieve load balancing.
1) Can anyone comment on how to make the FileResourceManager safely
coordinate with multiple JVMs all accessing the same directory ?
2) If #1 is possible, then it would surely be possible to write a JCA
adapter so these disk writes could occur in a distributed transaction
along with a DB write & JMS message publish.
Any thoughts?
Brant Boehmann
Software Engineer
Cadre5
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [transaction] cluster
Posted by Oliver Zeigermann <ol...@gmail.com>.
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
<ol...@gmail.com> wrote:
> On Thu, 06 Jan 2005 17:21:44 -0500, Brant Boehmann
> <br...@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
Re: [transaction] cluster
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Thu, 06 Jan 2005 17:21:44 -0500, Brant Boehmann
<br...@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
Re: [transaction] cluster
Posted by Brant Boehmann <br...@newmail.cadre5.com>.
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).
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???
I don't quite understand the semantics of 2-phase commit, but is it even
possible for the FileResourceManager to implement 2-phase commit?
I'm not an XA expert. What is the effect of a single commit operation
embedded in an XA transaction?
Oliver Zeigermann wrote:
>And, finally, thinking this to an end, you may want to consider using
>Jakarta Slide which is such a server, uses the FileResourceManager,
>speaks WebDAV as a standard and already has this JCA implementation I
>was talking about...
>
>Oliver
>
>On Thu, 6 Jan 2005 22:37:26 +0100, Oliver Zeigermann
><ol...@gmail.com> wrote:
>
>
>>One other thing: Having locks scattered across multiple JVMs then
>>there always is the hazard of deadlocks that can not be resolved.
>>Maybe it would be a better idea to have some sort of server running in
>>a single JVM that accepts requests via RMI or so.
>>
>>This would certainly be beyond the scope of the common tx package...
>>
>>Oliver
>>
>>
>>On Thu, 6 Jan 2005 21:51:26 +0100, Oliver Zeigermann
>><ol...@gmail.com> wrote:
>>
>>
>>>Hi Brant,
>>>
>>>1) This is currently not supported, but there was an approach to
>>>achieve this with java.nio.channels.FileChannel#lock from JDK 1.4. It
>>>was, however, abandoned as commons tx should remain compatible to
>>>JDK1.2. On the other hand such an extension would be pretty simple and
>>>could be optional for JDK1.4. It could be part of a 1.1 releases.
>>>
>>>2) Should be doable, especially with the helper classes in
>>>org.apache.commons.transaction.util.xa. A connection would likely be a
>>>dummy that simply returns an XAResource for the distributed
>>>transaction. Of couse no *real* two phase commit is supported by the
>>>FileResourceManager. I have implemented a JCA connector before and it
>>>is pretty simple conceptually, but confusing to implement. If you need
>>>support for all kinds of application servers it really is a pain in
>>>the *ss. I ended up supporting JBoss only...
>>>
>>>In short: What you want is not there, yet, but should be doable with
>>>reasonable effort. I am a bit short of time, so every contribution is
>>>highly welcome.
>>>
>>>Oliver
>>>
>>>On Thu, 06 Jan 2005 13:32:08 -0500, Brant Boehmann
>>><br...@newmail.cadre5.com> wrote:
>>>
>>>
>>>>I am in a situation where we have a cluster of app servers.
>>>>A requirement has arrived where writing/updating/deleting multiple
>>>>files on a file system must occur atomically.
>>>>The disk is NFS mounted across all nodes in the cluster. Each node needs
>>>>to be able to write to disk in order to achieve load balancing.
>>>>
>>>>1) Can anyone comment on how to make the FileResourceManager safely
>>>>coordinate with multiple JVMs all accessing the same directory ?
>>>>
>>>>2) If #1 is possible, then it would surely be possible to write a JCA
>>>>adapter so these disk writes could occur in a distributed transaction
>>>>along with a DB write & JMS message publish.
>>>>
>>>>Any thoughts?
>>>>
>>>>Brant Boehmann
>>>>Software Engineer
>>>>Cadre5
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [transaction] cluster
Posted by Oliver Zeigermann <ol...@gmail.com>.
And, finally, thinking this to an end, you may want to consider using
Jakarta Slide which is such a server, uses the FileResourceManager,
speaks WebDAV as a standard and already has this JCA implementation I
was talking about...
Oliver
On Thu, 6 Jan 2005 22:37:26 +0100, Oliver Zeigermann
<ol...@gmail.com> wrote:
> One other thing: Having locks scattered across multiple JVMs then
> there always is the hazard of deadlocks that can not be resolved.
> Maybe it would be a better idea to have some sort of server running in
> a single JVM that accepts requests via RMI or so.
>
> This would certainly be beyond the scope of the common tx package...
>
> Oliver
>
>
> On Thu, 6 Jan 2005 21:51:26 +0100, Oliver Zeigermann
> <ol...@gmail.com> wrote:
> > Hi Brant,
> >
> > 1) This is currently not supported, but there was an approach to
> > achieve this with java.nio.channels.FileChannel#lock from JDK 1.4. It
> > was, however, abandoned as commons tx should remain compatible to
> > JDK1.2. On the other hand such an extension would be pretty simple and
> > could be optional for JDK1.4. It could be part of a 1.1 releases.
> >
> > 2) Should be doable, especially with the helper classes in
> > org.apache.commons.transaction.util.xa. A connection would likely be a
> > dummy that simply returns an XAResource for the distributed
> > transaction. Of couse no *real* two phase commit is supported by the
> > FileResourceManager. I have implemented a JCA connector before and it
> > is pretty simple conceptually, but confusing to implement. If you need
> > support for all kinds of application servers it really is a pain in
> > the *ss. I ended up supporting JBoss only...
> >
> > In short: What you want is not there, yet, but should be doable with
> > reasonable effort. I am a bit short of time, so every contribution is
> > highly welcome.
> >
> > Oliver
> >
> > On Thu, 06 Jan 2005 13:32:08 -0500, Brant Boehmann
> > <br...@newmail.cadre5.com> wrote:
> > > I am in a situation where we have a cluster of app servers.
> > > A requirement has arrived where writing/updating/deleting multiple
> > > files on a file system must occur atomically.
> > > The disk is NFS mounted across all nodes in the cluster. Each node needs
> > > to be able to write to disk in order to achieve load balancing.
> > >
> > > 1) Can anyone comment on how to make the FileResourceManager safely
> > > coordinate with multiple JVMs all accessing the same directory ?
> > >
> > > 2) If #1 is possible, then it would surely be possible to write a JCA
> > > adapter so these disk writes could occur in a distributed transaction
> > > along with a DB write & JMS message publish.
> > >
> > > Any thoughts?
> > >
> > > Brant Boehmann
> > > Software Engineer
> > > Cadre5
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [transaction] cluster
Posted by Oliver Zeigermann <ol...@gmail.com>.
One other thing: Having locks scattered across multiple JVMs then
there always is the hazard of deadlocks that can not be resolved.
Maybe it would be a better idea to have some sort of server running in
a single JVM that accepts requests via RMI or so.
This would certainly be beyond the scope of the common tx package...
Oliver
On Thu, 6 Jan 2005 21:51:26 +0100, Oliver Zeigermann
<ol...@gmail.com> wrote:
> Hi Brant,
>
> 1) This is currently not supported, but there was an approach to
> achieve this with java.nio.channels.FileChannel#lock from JDK 1.4. It
> was, however, abandoned as commons tx should remain compatible to
> JDK1.2. On the other hand such an extension would be pretty simple and
> could be optional for JDK1.4. It could be part of a 1.1 releases.
>
> 2) Should be doable, especially with the helper classes in
> org.apache.commons.transaction.util.xa. A connection would likely be a
> dummy that simply returns an XAResource for the distributed
> transaction. Of couse no *real* two phase commit is supported by the
> FileResourceManager. I have implemented a JCA connector before and it
> is pretty simple conceptually, but confusing to implement. If you need
> support for all kinds of application servers it really is a pain in
> the *ss. I ended up supporting JBoss only...
>
> In short: What you want is not there, yet, but should be doable with
> reasonable effort. I am a bit short of time, so every contribution is
> highly welcome.
>
> Oliver
>
> On Thu, 06 Jan 2005 13:32:08 -0500, Brant Boehmann
> <br...@newmail.cadre5.com> wrote:
> > I am in a situation where we have a cluster of app servers.
> > A requirement has arrived where writing/updating/deleting multiple
> > files on a file system must occur atomically.
> > The disk is NFS mounted across all nodes in the cluster. Each node needs
> > to be able to write to disk in order to achieve load balancing.
> >
> > 1) Can anyone comment on how to make the FileResourceManager safely
> > coordinate with multiple JVMs all accessing the same directory ?
> >
> > 2) If #1 is possible, then it would surely be possible to write a JCA
> > adapter so these disk writes could occur in a distributed transaction
> > along with a DB write & JMS message publish.
> >
> > Any thoughts?
> >
> > Brant Boehmann
> > Software Engineer
> > Cadre5
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [transaction] cluster
Posted by Oliver Zeigermann <ol...@gmail.com>.
Hi Brant,
1) This is currently not supported, but there was an approach to
achieve this with java.nio.channels.FileChannel#lock from JDK 1.4. It
was, however, abandoned as commons tx should remain compatible to
JDK1.2. On the other hand such an extension would be pretty simple and
could be optional for JDK1.4. It could be part of a 1.1 releases.
2) Should be doable, especially with the helper classes in
org.apache.commons.transaction.util.xa. A connection would likely be a
dummy that simply returns an XAResource for the distributed
transaction. Of couse no *real* two phase commit is supported by the
FileResourceManager. I have implemented a JCA connector before and it
is pretty simple conceptually, but confusing to implement. If you need
support for all kinds of application servers it really is a pain in
the *ss. I ended up supporting JBoss only...
In short: What you want is not there, yet, but should be doable with
reasonable effort. I am a bit short of time, so every contribution is
highly welcome.
Oliver
On Thu, 06 Jan 2005 13:32:08 -0500, Brant Boehmann
<br...@newmail.cadre5.com> wrote:
> I am in a situation where we have a cluster of app servers.
> A requirement has arrived where writing/updating/deleting multiple
> files on a file system must occur atomically.
> The disk is NFS mounted across all nodes in the cluster. Each node needs
> to be able to write to disk in order to achieve load balancing.
>
> 1) Can anyone comment on how to make the FileResourceManager safely
> coordinate with multiple JVMs all accessing the same directory ?
>
> 2) If #1 is possible, then it would surely be possible to write a JCA
> adapter so these disk writes could occur in a distributed transaction
> along with a DB write & JMS message publish.
>
> Any thoughts?
>
> Brant Boehmann
> Software Engineer
> Cadre5
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org