jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: [jr3] EventJournal / who merges changes
Date Sat, 27 Feb 2010 10:45:19 GMT

On 26 Feb 2010, at 12:43, Thomas Müller wrote:

> Hi Ian,
> 
> Could you describe your use case?

Multiple threads adding child nodes to the same parent node, which IIUC are stored as multivalue
properties in 1.x 

For instance, more than 1 thread calling UserManager.createUser(userId,shardPath(useId)) where
shardPath(userId) results in a subtree generated from the userId to reduce contention, although
we still see it.


> 
>> probability of conflict when updating a multivalued property is reduced
> 
> What methods do you call, and how should the conflict be resolved?
> Example: if you currently use the following code:
> 
> 1) session1.getNode("test").setProperty("multi", new String[]{"a", "b"},..);
> 2) session2.getNode("test").setProperty("multi", new String[]{"d", "e"},..);
> 3) session1.save();
> 4) session2.save();
> 
> Then that would be a conflict. How would you resolve it? One option is
> to silently overwrite in line 4.

yes although this is not really a big problem for us since the application code can do something.
In the past we have used a custom in JVM lock manager to control this type of update where
we know there is high concurrency. We avoided cluster wide JCR locks since they generate extra
cluster traffic at a latency that doesn't really help the locking problem.

To recap, the reason I said multivalue is because I thought child nodes are essentially multivalue
properties in 1.x, not because we see conflicts with setProperty.

Ian


> 
> Regards,
> Thomas


Mime
View raw message