Well, Jonathan explanations are much more accurate than mine. :) I took the word serialization as meaning kind of isolation between commits, which is not very smart. Sorry to have introduce more confusion in this.
Pierre -----Message d'origine----- De : Savvas-Andreas Moysidis [mailto:savvas.andreas.moysi...@googlemail.com] Envoyé : mercredi 9 février 2011 17:04 À : solr-user@lucene.apache.org Objet : Re: Concurrent updates/commits Hello, Thanks very much for your quick replies. So, according to Pierre, all updates will be immediately posted to Solr, but all commits will be serialised. But doesn't that contradict Jonathan's example where you can end up with "FIVE 'new indexes' being warmed"? If commits are serialised, then there can only ever be one Index Searcher being auto-warmed at a time or have I got this wrong? The reason we are investigating commit serialisation, is because we want to know whether the commit requests will be blocked until the previous ones finish. Cheers, - Savvas On 9 February 2011 15:44, Pierre GOSSE <pierre.go...@arisem.com> wrote: > > However, the Solr book, in the "Commit, Optimise, Rollback" section > reads: > > "if more than one Solr client were to submit modifications and commit > them > > at similar times, it is possible for part of one client's set of changes > to > > be committed before that client told Solr to commit" > > which suggests that requests are *not* serialised. > > I read this as "If two client submit modifications and commits every couple > of minutes, it could happen that modifications of client1 got committed by > client2's commit before client1 asks for a commit." > > As far as I understand Solr commit, they are serialized by design. And > committing too often could lead you to trouble if you have many warm-up > queries (?). > > Hope this helps, > > Pierre > -----Message d'origine----- > De : Savvas-Andreas Moysidis [mailto: > savvas.andreas.moysi...@googlemail.com] > Envoyé : mercredi 9 février 2011 16:34 > À : solr-user@lucene.apache.org > Objet : Concurrent updates/commits > > Hello, > > This topic has probably been covered before here, but we're still not very > clear about how multiple commits work in Solr. > We currently have a requirement to make our domain objects searchable > immediately after the get updated in the database by some user action. This > could potentially cause multiple updates/commits to be fired to Solr and we > are trying to investigate how Solr handles those multiple requests. > > This thread: > > http://search-lucene.com/m/0cab31f10Mh/concurrent+commits&subj=commit+concurrency+full+text+search > > suggests that Solr will handle all of the lower level details and that > "Before > a *COMMIT* is done , lock is obtained and its released after the > operation" > which in my understanding means that Solr will serialise all update/commit > requests? > > However, the Solr book, in the "Commit, Optimise, Rollback" section reads: > "if more than one Solr client were to submit modifications and commit them > at similar times, it is possible for part of one client's set of changes to > be committed before that client told Solr to commit" > which suggests that requests are *not* serialised. > > Our questions are: > - Does Solr handle concurrent requests or do we need to add synchronisation > logic around our code? > - If Solr *does* handle concurrent requests, does it serialise each request > or has some other strategy for processing those? > > > Thanks, > - Savvas >
