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 stefan.guggisberg@gmail.com
 designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOFYJNb0j-4aedHcS71vEv+EEemqp-hxscjJ_eoqC1BYUsgUzg@mail.gmail.com>
References: 
 <CAOFYJNb0j-4aedHcS71vEv+EEemqp-hxscjJ_eoqC1BYUsgUzg@mail.gmail.com>
Date: Mon, 2 Apr 2012 18:34:35 +0200
Message-ID: 
 <CAFYk8Nk840X=hxYVZ9RO1M1yFRe3ytSd2o3-6TbsVbwuZCE8+A@mail.gmail.com>
Subject: Re: Lifetime of revision identifiers
From: Stefan Guggisberg <stefan.guggisberg@gmail.com>
To: oak-dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 31, 2012 at 12:39 PM, Jukka Zitting <jukka.zitting@gmail.com> w=
rote:
> 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:
>
> =A0 =A0String revision =3D mk.getHeadRevision();
> =A0 =A0String root =3D 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 sp=
an
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.

cheers
stefan

>
> 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