jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Clustering and consistency
Date Tue, 09 Oct 2007 07:31:15 GMT

On 10/9/07, Dominique Pfister <dominique.pfister@day.com> 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.


Jukka Zitting

View raw message