"mircea.markus" wrote : | anonymous wrote : But the DummyTransactionManager says it synchronizes in-memory only, so cache clients on two different machines wouldn't be sync'd. | | | what that means is that locks will be acquired on the node on which the tx was initiated only. If you have n1 and n2, two nodes in an replicated cluster, | and an transaction having a write lock (WL) on fqn_1 on n1, then same fqn_1 is not locked on n2. In other words, transactions only aquire local locks. Locks are acquired on n2 only at commit time: at this point all operations performed on n1 will be executed in same sequence on n2 (including lock acquisition).
Unfortunately that doesn't sound like it will work for me... The locking API assumes that once you pass the lock() call, you have exclusive access to those resources... So that's very different from attempting to commit changes on implicitly shared resources. "mircea.markus" wrote : | If you need eager remote locking (i.e. acquire locks on all nodes of a cluster at write time) I suggest you to take a look at infinispan: http://www.jboss.org/infinispan A grid computing solution? That sounds like a bit overkill... Could you point to an example of how this would work? I'm going to try my put() method, which would work something like this: To lock object O: 1. val = cache.put( '/locks', O, 'lock' ) 2a. If val == null, we have the lock (no previous 'put') 2b. Else (val != null ) somebody else locked it first. Use a cache listener to wait for removed nodes 3a. Lock owner in (2a) proceeds. When finished, call cache.remove( '/locks', O ) 3b. Contenders from (2b) get notified and return to (1) Does that sound like it will work? Since it's a put, the operations will acquire a write lock, and subsequently (I assume) guarantees that two concurrent puts could no both return 'null' for the previous value. What do you think? My other option would be to fall back to ZooKeeper, since I know that works :) But I really don't want to use 3 different frameworks in order to accomplish this :) Thanks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238472#4238472 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238472 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
