jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: [jr3] EventJournal / who merges changes
Date Sat, 27 Feb 2010 15:00:10 GMT
On Sat, Feb 27, 2010 at 11:45 AM, Ian Boston <ieb@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
>
>

Mime
View raw message