lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Solr updateRequestHandler and performance vs. atomicity
Date Mon, 24 May 2010 13:10:10 GMT
Hi all,

It seems to me that the "commit" logic in the Solr updateRequestHandler (or wherever the logic
is actually located) conflates two different semantics.  One semantic is what you need to
do to make the index process perform well.  The other semantic is guaranteed atomicity of
document reception by Solr.

In particular, it would be nice to be able to post documents in such a way that you can guarantee
that the document is permanently in Solr's queue, safe in the event of a Solr restart, etc.,
even if the document has not yet been "committed".

This issue came up in the LCF talk that I gave, and I initially thought that separating the
two kinds of events would necessarily be an LCF change, but the more I thought about it the
more I realized that other Solr indexing clients may also benefit from such a separation.

Does anyone agree?  Where should this logic properly live?


View raw message