On Sat, Feb 27, 2010 at 11:45 AM, Ian Boston <i...@tfd.co.uk> wrote:
>
> 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
not quite, the parent-child relationship is currently (i.e. jr
1.x-2.0) stored as a list of name-uuid pairs in the parent state.
cheers
stefan
>
> 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,
that's not correct, see my previous comment.
cheers
stefan
> not because we see conflicts with setProperty.
>
> Ian
>
>
>>
>> Regards,
>> Thomas
>
>
