jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Lifetime of revision identifiers
Date Mon, 02 Apr 2012 16:34:35 GMT
On Sat, Mar 31, 2012 at 12:39 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> The revision identifiers returned by methods like
> MicroKernel.getHeadRevision() are plain strings so in theory I could
> write one down on a piece of paper, lock it in a safe, and come back
> ten years later expecting the identifier to give me access to the
> repository content as it existed a decade ago.
> Currently there's nothing in the documented MicroKernel contract that
> prevents me from expecting that the above use case would work. This is
> troublesome as it means that *no* past state of the repository should
> ever be automatically cleaned out as garbage.

right, there's currently no mention of lifetime of revisions in the javadoc.
i agree that this needs to be clearly specified.

> To allow automatic garbage collection without unexpectedly breaking
> client expectations, we should define some rules on the expected
> lifetime of revision identifiers. Without rules like that a client
> can't even do the following without worrying about potential
> interference from the garbage collector:
>    String revision = mk.getHeadRevision();
>    String root = mk.getNodes(revision, "/");
> Since the revision identifiers are plain strings, we can't leverage
> the standard garbage collector of the JVM and simply declare that all
> revisions identifiers will remain valid for at least as long as they
> are being referenced by some client. Thus a lease mechanism like
> "revision identifiers remain valid for at least N minutes since last
> access" may be needed. A client like a long-lived JCR Session would
> then need to either periodically refresh to the latest revision or
> extend its "lease" on an earlier revision.

i think that we should specify that revisions have a certain guaranteed
life span, e.g. N minutes, and that a client cannot expect to be able
to read a revision exceeding that life span.

however, what should the guaranteed life span be?
1  minute, 1 hour, 1 day?

i don't think that we should allow clients to explicitly extend the life span
of a specific revision. this would IMO unnecessarily complicate the GC
logic and it would allow misbehaved clients to compromise the stability
of the mk.


> Or we could combine these approaches by defining a Revision interface
> for local Java clients and an accompanying Revision-String mapping
> with defined lease handling for remote access.
> BR,
> Jukka Zitting

View raw message