IndexEditor and Commit Failure

[Chetan Mehrotra <ch...@gmail.com>]

Hi,

Currently the various IndexEditor (Lucene,Property and Solr) are
invoked as part of CommitHook.processCommit call whenever a JCR
Session is saved.

In case the commit fails would it leave the Index state in inconsistent state?

For PropertyIndex I think it would be fine as the index content is
also part of same commit and hence would not be committed. But for
other indexes the index data would have been saved (sort of 2 phase
commit) and it would not be possible to roll them back leaving them
with data which has not been committed.

And more over such commit failure would occur *after * a proper commit
has been done so the changes done to index state as part of failed
commit would overwrite the changes done as part of successful commit.

Should not the IndexEditor work as part of PostCommitHook so that they
always work on proper committed content?

Chetan Mehrotra

Re: IndexEditor and Commit Failure

[Chetan Mehrotra <ch...@gmail.com>]

> The lucene index is asynchronous

Okie I missed that part completely i.e. OAK-763. Yup with that used
for such indexers this problem would not be observed.

Thanks for the pointer Alex!!

Chetan Mehrotra

Re: IndexEditor and Commit Failure

[Alex Parvulescu <al...@gmail.com>]

Hi Chetan,

The lucene index is asynchronous and the way it works is it (periodically)
branches the current state and runs a diff to update the index data. [0]
This shouldn't include the conflicts you refer to, but I may be wrong here.

My guess is the solr index will pass on an async model too, soon enough.

best,
alex

[0]
http://svn.us.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/AsyncIndexUpdate.java?view=markup#l81





On Wed, Oct 16, 2013 at 1:26 PM, Chetan Mehrotra
<ch...@gmail.com>wrote:

> Hi,
>
> Currently the various IndexEditor (Lucene,Property and Solr) are
> invoked as part of CommitHook.processCommit call whenever a JCR
> Session is saved.
>
> In case the commit fails would it leave the Index state in inconsistent
> state?
>
> For PropertyIndex I think it would be fine as the index content is
> also part of same commit and hence would not be committed. But for
> other indexes the index data would have been saved (sort of 2 phase
> commit) and it would not be possible to roll them back leaving them
> with data which has not been committed.
>
> And more over such commit failure would occur *after * a proper commit
> has been done so the changes done to index state as part of failed
> commit would overwrite the changes done as part of successful commit.
>
> Should not the IndexEditor work as part of PostCommitHook so that they
> always work on proper committed content?
>
> Chetan Mehrotra
>