Yes, we'll probably go towards that path as our index files are relatively small, so auto warming might not be extremely useful in our case.. Yep, we do realise the difference between a db and a Solr commit. :)
Thanks. On 9 February 2011 16:15, Walter Underwood <wun...@wunderwood.org> wrote: > Don't think "commit", that is confusing. Solr is not a database. In > particular, it does not have the "isolation" property from ACID. > > Solr indexes new documents as a batch, then installs a new version of the > entire index. Installing a new index isn't instant, especially with warming > queries. Solr creates the index, then warms it, then makes it available for > regular queries. > > If you are creating indexes frequently, don't bother warming. > > wunder > == > Walter Underwood > Lead Engineer, MarkLogic > > On Feb 9, 2011, at 8:03 AM, Savvas-Andreas Moysidis wrote: > > > 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 > >> > > > > >
