Hi,
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.
Michael
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.
>
> WDYT?
>
> BR,
>
> Jukka Zitting
|