commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brant Boehmann <brant.boehm...@newmail.cadre5.com>
Subject Re: [transaction] cluster
Date Thu, 06 Jan 2005 22:21:44 GMT
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
><oliver.zeigermann@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
>><oliver.zeigermann@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
>>><brant.boehmann@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


Mime
View raw message