Hi, On 10/9/07, Dominique Pfister <[EMAIL PROTECTED]> wrote: > > But do we have a good picture of what will happen if multiple cluster > > nodes concurrently update the same content nodes? > > What happens is the following: before actually being able to store its > changes, a cluster node has to "lock and sync", i.e. it must first > obtain a non-shareable lock on the journal (which is either a file or > a database table) and will then read all changes upto the latest > revision.
Ah, you're right! That should work fine. Looking at the code I never realized this was happening, but now that you mentioned it I was able to find the relevant calls in DefaultRecordProducer and AppendRecord. Is there a rationale for having the calls in these locations, or should we consider refactoring the code somehow? I'd find something like journal.append(record) followed by journal.unlock() more intuitive than record.update(), but I guess that would spread both the journal reference and the locking functionality to a number of places around Jackrabbit. BR, Jukka Zitting
