On 6/2/06, Simon Willnauer <[EMAIL PROTECTED]> wrote:
The problem here is that there is no action comparable to commit. The entry
comes in and will be added to the storage. The delete will be queued but
when should the delete operation start. Waiting for the writer to idle?! We
could do it that way. but if a search request comes in the old entries will
be found an can be retrieved from the storage. In that case I have to hold
the already added but not yet deleted entries in a storage cache to prefent
the storage from retrieving outdated and updated entries because they have
the same ID.
You use multiple indexSearcher instances to serve searches right?
There is normally only a single searcher open at a time (except when warming).
A main "registered" searcher handles all live requests. When a new
searcher is opened, it is warmed up (requests run against it in the
background, caches pre-populated, etc) and then it is registered.
so when
all the deletes are done you have to reopen all indexsearchers again right?!
Just one.
So this would happen quiet often due to updates and inserts.
Hmm it is more and more a bad idea to use a lucene index as a storage.
Rather go straight to a Database.
Yes, if you need to be able to *instantly* retrieve (but not search)
updates you just inserted, and you need to support a high volume of
updates and queries.
You could also do that in-memory by supporting retrieval by id from
your "batch" of documents not yet "committed" in Lucene. Only
downside is it's volatile.
-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search server
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
