Hi, On Fri, Mar 20, 2009 at 10:36 AM, Ian Boston <[email protected]> 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. BR, Jukka Zitting
