jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Pfister <dpfis...@adobe.com>
Subject Re: Lifetime of revision identifiers
Date Tue, 03 Apr 2012 09:47:58 GMT

I made a second thought, and I'm no longer sure I would allow a revision to be reachable by
some client interaction. In the current design, the GC will copy the head revision to the
"to store" plus all the revisions that are either newly created (by some commit call coming
in later) or still manipulated (by a commit that started earlier but where the internal commit
builder is still not finished). I'd extend this design by copying all revisions that were
created in some fixed interval (e.g. 10 minutes) before the head revision was created, and
see whether this will suffice.


On Apr 3, 2012, at 11:05 AM, Dominique Pfister wrote:

> Hi,
> On Apr 2, 2012, at 7:28 PM, Jukka Zitting wrote:
>> Hi,
>> On Mon, Apr 2, 2012 at 6:34 PM, Stefan Guggisberg
>> <stefan.guggisberg@gmail.com> wrote:
>>> 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.
>> This would notably complicate things in oak-core and higher up. Any
>> large batch operations would have to worry about the underlying
>> revisions becoming unavailable unless they are continuously updated to
>> the latest head revision.
>> I don't think allowing lease extensions would complicate garbage
>> collection too much. All I'm asking is that the collector should look
>> at the "last access time" instead of the "create time" of a revision
>> to determine whether it's still referenceable or not.
> Sounds reasonable, as long as you explicitely access the revision first, and then the
nodes it contains. Things get more complicated if you'd "hang on" to some node in some revision
and then expect that this revision stays alive.
> Regards
> Dominique
>> BR,
>> Jukka Zitting

View raw message