jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Lifetime of revision identifiers
Date Sun, 01 Apr 2012 20:26:57 GMT


Couldn't we just block a revision from being garbage collected for a 
certain (configurable) time each time it is accessed? That would 
correspond to the lease model where acquiring/extending the lease is 
implicitly done on access.

In general I wouldn't worry too much about garbage collection until we 
have some figures on how much garbage actually accumulates.


On 31.3.12 11:39, Jukka Zitting 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.
> 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.
> 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