On Sat, Mar 31, 2012 at 12:39 PM, Jukka Zitting <jukka.zitt...@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. 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
