lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <>
Subject Re: Enhance SnapshotDeletionPolicy to allow taking multiple snapshots
Date Tue, 27 Apr 2010 15:18:31 GMT
That's an interesting point ...

I still think we should use IDs though, because the application that uses
this (like me :)) may want to persist the snapshots used elsewhere, in case
the JVM crashes. That's another weak point of SDP today - if the JVM dies,
your snapshot might get deleted, which depending on why you took it may not
be what you want. So, what I've implemented actually allows init'ing SDP w/
existing snapshots information (a Map from String [id] to String
[segmentsName]), so that when you open IndexWriter, the wrapped DP won't
delete those snapshots for you (onInit will ensure that).

Another thing I've run into is several processes that take a snapshot over
the same commit. The IDs allow me to safely release only one snapshot, but
the commit will remain because it's snapshotted by another process. While
it's still supported if release() receives IndexCommit (I can decRef that IC
or something), it will be less clear?

So ... while both those scenarios are still supported if we don't use IDs, I
think IDs will be easier for apps to integrate w/ that feature. Sometimes
it's useful why a snapshot is held, and if you use a meaningful ID, like
"copyIndex[timestamp]", one can determine that snapshot is not needed
anymore. In fact, some comments I've received about using Id were that Ids
are too simple, and perhaps a more complex object can be associated w/ a
snapshot. But for now I think Id is enough, until proven otherwise.

What do you think?


On Tue, Apr 27, 2010 at 6:04 PM, Michael McCandless <> wrote:

> On Tue, Apr 27, 2010 at 11:03 AM, Earwin Burrfoot <>
> wrote:
> > I think we should enhance SDP.
> > I also think we shouldn't do IDs. snapshot() returns IndexCommitPoint,
> > release() should get a parameter accepting IndexCommitPoint, that's
> > all.
> +1
> Mike
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message