On 11/11/2013 07:29 PM, Jukka Zitting wrote:
Hi,
On Mon, Nov 11, 2013 at 6:10 AM, Michael Dürig <[email protected]> wrote:
On 8.11.13 10:37 , Alexander Klimetschek wrote:
Regarding journaled observation: retrieving a journal with
ObservationManager#getEventJournal can allow access to events that
happend earlier, right?
The spec. doesn't say much here. I'd interpret it as getEventJournal()
returns the journal from the point where that call was made rather then from
the beginning of times.
This interpretation makes the event journal essentially useless, as
one could achieve the same functionality with a normal observation
listener.
The point of journaled observation is to be able to access past
events, which the spec confirms (section 12.6):
"Journaled observation allows an application to periodically connect
to the repository and receive a report of changes that have occurred
since some specified point in the past (for example, since the last
connection)."
Of course section 12.6.2 contradicts that by essentially giving the
repository free reign to decide which (if any) events to include in
the journal.
Far more problematic (broken really) is the fact that the spec. uses Dates to
access/order (skipTo) the events. Which is unreliable and useless in a clustered
environment. Meaning: unreliable for any serious use-case.
Luckily, Jackrabbit internally maintains a properly ordered and cluster-wide
journal item revision, as needed anyway for its cluster synchronization.
At Hippo we expose and use this feature through an extended RevisionEventJournal
[1] adding a skipToRevision(long) method and an RevisionEvent [2] exposing the
current event its revision.
Implementing this on top of Jackrabbit was really trivial [3] and enables us to
reliably and asynchronously process past events, in proper order, for things
like cross-cluster synchronization/replication, etc.
I'm not following the current state of things at Oak enough to know if it also
will provide some kind of guaranteed orderable and cluster-wide transaction
revision/timestamp/whatever. But it definitely would be worthwhile (and
important to us) to be available. Through a fixed/extended EventJournal
interface like we implemented on top of Jackrabbit or something else doesn't
really matter, but the functionality IMO is important enough to take into
consideration for Oak.
Regards, Ate
[1]
http://svn.onehippo.org/repos/hippo/hippo-cms7/repository/trunk/api/src/main/java/org/hippoecm/repository/api/RevisionEventJournal.java
[2]
http://svn.onehippo.org/repos/hippo/hippo-cms7/repository/trunk/api/src/main/java/org/hippoecm/repository/api/RevisionEvent.java
[3]
http://svn.onehippo.org/repos/hippo/hippo-cms7/repository/trunk/engine/src/main/java/org/apache/jackrabbit/core/observation/RevisionEventJournalImpl.java
So instead of the spec, I think we should look at existing client code
to determine what kind of expectations they have.
BR,
Jukka Zitting
