2008/12/4 Shalin Shekhar Mangar <[EMAIL PROTECTED]>: > If each CMS process has a consistent view of the data and it wishes to > update Solr with that data, where is the question of inconsistency here?
Because it is difficult to guarantee the order of processing across a distributed system while minimising the time shared locks are held. There is an interesting discussion on this here: http://www.allthingsdistributed.com/2007/12/eventually_consistent.html > >> But I cannot see how to ensure that the reindexing >> operations (that result in a delete and add for the document) are >> processed in the order R1 then R2, rather than R2 then R1. In the >> second case the index record is now inconsistent with the content >> object in the database. > > > When you need to update a document in Solr, you need to send the complete > document and it will automatically do the replace. They will be visible to > searchers when you call commit on Solr. From your CMS's perspective, it is a > single operation. I hope I am understanding your problem correctly. I think we have a slight misunderstanding here. Because there are many CMS processes it is possible that the same document will be updated concurrently (from different web requests). In this case two updates are sent (one by each process). The problem arises when the two update requests are processed in a different order to the original database transactions. I guess the only way to achieve consistency is to stage my indexed data in a database table and trigger a DataImportHandler to perform delta imports after each transaction. >> From what I can tell this conditional indexing feature is not >> supported by Solr. Might it be supported by Lucene but not exposed by >> Solr? >> > > No this is not supported by either of Lucene/Solr. This is a pity, eventual consistency is a nice model. Regards, Laurence
