jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: InvalidItemStateException with concurrent threads
Date Fri, 20 Mar 2009 11:02:44 GMT

On Fri, Mar 20, 2009 at 10:36 AM, Ian Boston <ieb@tfd.co.uk> wrote:
> besides, with a multiuser system, randomness will ensure that at some point
> *every* change is potentially non-mergable.

In an infinite university everything that can happen will happen. But
that doesn't mean that pink elephants will start mystically appearing
from thin air.

If your users are modifying random nodes, and you know the frequency
and duration of typical modifications, then it's fairly
straightforward to calculate a strategy for distributing the nodes in
a way that the likelihood of a conflict is less than 1% during the
entire lifetime of your system.

And if your usage patterns aren't random or otherwise highly
distributed (for example if most users will only be modifying a
limited set of recent nodes), then you in any case need to figure out
what to do with conflicts.

The storage layer can either a) forcibly merge conflicting changes, b)
avoid conflicts by blocking concurrent users, or c) make conflicting
changes fail. Jackrabbit opts for mode c, and you can explicitly
select mode b with locking if you want that behaviour.


Jukka Zitting

View raw message