Rajesh parab wrote:
I am talking about transaction support in Lucene only. If there is a failure
during insert/update/delete of document inside the index, there is no way to
roll back the operation and this will keep the index in in-consistent state.
OK, I see. Then you should also look at Solr, which puts "Lucene
only" transactional semantics on top, in that you can do a bunch of
add/update/deletes to your index but only on calling "commit" are
these changes copied to a snapshot (using hard links in the
filesystem) and distributed to searchers.
Also, the lockless commits patch (not committed yet but I think
close):
http://issues.apache.org/jira/browse/LUCENE-701
gets us closer to enabling transactions. With that patch, every
commit from Lucene writes to a segments_N file (N increments on every
commit). We keep only the last segments_N file.
But, with a small-ish change beyond that patch, which has been briefly
touched on the dev list & Jira, we could have Lucene keep more than
just the last segments_N file (and all segment files referenced by
them). This would enable you to open a Lucene index explicitly at
prior commit point. Then we could enable transactions over that by
recording the segments_N at which you began your transaction, not
deleting it, and then rolling back to it if any error had occurred.
This same approach could be used to make Lucene's "point in time"
searching explicit, and, work correctly on NFS.
I will open a Jira issue to start tracking these ideas ... but I think
it's a ways off before this would be available in a release.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
