jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@adobe.com>
Subject Re: Observation
Date Fri, 08 Nov 2013 21:37:06 GMT
On 08.11.2013, at 03:45, Michael Dürig <mduerig@apache.org> wrote:
> Just occurred to me that in JCR 2.1 the current way of specifying a 
> filter is deprecated in favour of a dedicated EventFilter class. I think 
> this sketches a way forward here.

Interesting! Albeit it just is a simple data class to contain all the different parameters
that make the current ObservationManager#addEventListener a bit ugly. And you are supposed
to have the repository implementation create it for you using ObservationManager#createEventFilter.
But at least it is an interface to work with (aka to extend from) and it is the same for both
normal and journaled observation.

Regarding journaled observation: retrieving a journal with ObservationManager#getEventJournal
can allow access to events that happend earlier, right? So the goal of supporting filtering
as early as possible wouldn't quite work here, as you still have to keep access to all events
for anyone asking for them later. OTOH, the spec seems to leave journal implementations a
lot of freedom on how many events are still accessible at all (which makes me wonder how much
you can make application code rely on it) [0].

I assume due to the MVCC principle in oak it is easy to implement the journal and it is cheap
to "keep all events". How far can you go back? I assume that depends on the implementation,
e.g. when the last tar optimization happened?

[0] http://www.day.com/specs/jcr/2.0/12_Observation.html#12.6.2%20Journaling%20Configuration

View raw message