"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#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...