Hi, On Tue, Aug 10, 2010 at 12:21 PM, Dominik Klaholt <[email protected]> wrote: > I have a problem with the following use-case: A user reads the current value > of a property of a node, then makes a decision based upon the read value and > changes the value. > Is there any way, besides locking, to makes this use-case atomic... thus > enabling a kind of a "test&set"-mechanism? The purpose would be that a > second user cannot change the value of interest right in-between the read > and the write of the first user, which could cause an inconsistent > persistent state. > Locking does not sound as a perfect match for this use-case, as it locks the > entire node and thus also prohibits access to other properties.
Locking's the way to go, unless you want to use some other non-JCR synchronization mechanism. If you want more fine-grained locking, you can always add a lockable child node that only contains this one property. This way locking won't affect your other content. BR, Jukka Zitting
