Thanks very much Em. - Savvas
On 9 February 2011 16:22, Savvas-Andreas Moysidis < savvas.andreas.moysi...@googlemail.com> wrote: > 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 >> >> >> >> >> >> >> >
