Sorry I was not clear on this. I just meant that you will not have any
trouble opening a Reader on an index with a lock file. You may have
trouble deleting with that Reader
When you are using a Reader as a "Writing Reader" i.e. deleting, then
you pretty much have to consider it as a Writer. I
Hello,
>
> The lock file is only for Writers. The lock file ensures that
> even two
> writers from two JVM's will not step on each other. Readers
> do not care
> about what the writers are doing or whether there is a lock
> file...
Is this always true? The deleteDocuments method of the Index
The lock file is only for Writers. The lock file ensures that even two
writers from two JVM's will not step on each other. Readers do not care
about what the writers are doing or whether there is a lock file...even
more so with the new generational files i believe.
- Mark
vcampa wrote:
Stein
Steinert, Fabian wrote:
>
> Hi,
> you do not need to writer.close() the IndexWriter at all to make changes
> visible.
> When IndexWriter is constructed with autoCommit = true flag set,
> calling writer.flush() will do.
>
Ok, but what about the write.lock? IndexWriter releases its write.lock on
Hi,
you do not need to writer.close() the IndexWriter at all to make changes
visible.
When IndexWriter is constructed with autoCommit = true flag set,
calling writer.flush() will do.
This way you can keep your single IndexWriter at App-level handling all the
synchonization.
Have a look at
Hello,
> I'm developing a web app with struts that need to embed lucene
> functionalities. I need that my app adds documents to the
> index after that a
> document is added (documents are very few, but of large
> size). I read that i
> have to use a single instance of indexwriter to edit the
>
