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
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 wrote:
> Don't think "commit", t
sidis [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 wi
Hi Savvas,
well, although it sounds strange: If a commit happens, a new Index Searcher
is warming. If a new commit happens while a 'new' Index Searcher is warming,
another Index Searcher is warming. So, at this point of time, you got 3
Index Searchers: The old one, the 'new' one and the newest on
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. Sol
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
> 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 su
Solr does handle concurrency fine. But there is NOT "transaction isolation"
like you'll get from an rdbms. All 'pending' changes are (conceptually, anyway)
held in a single queue, and any commit will commit ALL of them. There isn't
going to be any data corruption issues or anything from concurre
