On 17 Feb 2010, at 14:34, Jukka Zitting wrote: > Hi, > > On Wed, Feb 17, 2010 at 11:53 AM, Ian Boston <i...@tfd.co.uk> wrote: >> On 17 Feb 2010, at 10:43, Jukka Zitting wrote: >>> I'm not aware of anything like that, though there's been some >>> discussion about persistence on top of distributed databases or hash >>> tables. The main problem with such approaches is the eventual >>> consistency model that can be troublesome for the current Jackrabbit >>> architecture. >> >> Is that because, in a cluster one JR node might get an event that an >> Item exists, but its not yet present on the backend its connected to, >> and there are no guarantees over the order in which items appear, >> so, for instance, the hierarchy manager might find a child but not >> the parent? > > Exactly. The current Jackrabbit architecture assumes that the > underlying persistence store is always (not just eventually) > consistent.
Ok, I'm looking into ways to address that. The other one, I suspect is going to be the sequence ID on the journal event stream, which IIRC needs to be sequential so the journal can be replayed, also since the biggest source of eventually consistent errors is going to be that journal stream I am thinking binding the journal with the PM might allow remote nodes to know when a local item is out of date, if an item in the local PM is stale, and which server to get the latest item copy from. That assumes nothing changes without a journal record being emitted. I want to avoid sending the journal via storage. > >> Do you have any pointers to the discussions so I can go and read ? > > It's been mostly coffee room discussions so far, but I'll bring up the > topic soon on dev@ as a part of a larger Jackrabbit 3 roadmap > discussion. I commented on you JR3 rfi, but I am still thinking about JR2 > > BR, > > Jukka Zitting
