On Fri, Dec 5, 2008 at 2:42 AM, Laurence Rowe <[EMAIL PROTECTED]> wrote:
> > We currently have a single Solr server, with a single index. There are > a number of CMS processes distributed over a number of servers, with > each CMS process sending an update to the Solr index when changes are > made to a content object. > > My concern is that a scenario is possible where a content object is > changed and reindexed concurrently by two CMS processes. The database > ensures consistency within the CMS, these transactions get comitted as > T1 and T2. 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? > 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 would like to supply a transaction id with the reindex request, and > configure Solr such that a reindex operation is processed if and only > if the supplied transaction id is greater than the currently indexed > transaction id. > > Otherwise the only way I can see to guarantee consistency is 1) have > index operations processed by a single writer, or 2) commit the index > operation between database prepare and commit statements. > > The first is not desirable as we introduce a single point of failure > (in addition to the single Solr server) and delay updating the index. > The second is not desirable because it reduces the throughput of the > database, and with a distributed Solr setup would not solve the > problem. > > 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. -- Regards, Shalin Shekhar Mangar.
