Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.212.42 as permitted sender)
MIME-Version: 1.0
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Sat, 31 Mar 2012 12:39:08 +0200
Message-ID: 
 <CAOFYJNb0j-4aedHcS71vEv+EEemqp-hxscjJ_eoqC1BYUsgUzg@mail.gmail.com>
Subject: Lifetime of revision identifiers
To: Oak devs <oak-dev@jackrabbit.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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.

WDYT?

BR,

Jukka Zitting