We us an autocommit with Solr and I've had this worry too - apparently if you get a hard crash Solr will roll back the not-yet-committed docs.
I don't think it's happened more than once in a year, but still possible. -Peter On Mon, May 24, 2010 at 9:10 AM, <karl.wri...@nokia.com> wrote: > 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? > > Thanks, > Karl > > > > -- Peter M. Wolanin, Ph.D. Momentum Specialist, Acquia. Inc. peter.wola...@acquia.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
