Right.
But, that can, and should, be done outside of the Lucene core.
Mike
robert engels wrote:
You must get the write lock before opening the reader if you want
transactional consistency and are performing updates.
No other way to do it.
Otherwise.
A opens reader.
B opens reader.
A performs query decides an update is needed based on results
B performs query decides an update is needed based on results
B gets write lock
B updates
B releases
A gets write lock
A performs update - ERROR. A is performing an update based on stale
data
If A & B want to update an index, it must work as:
A gets lock
A opens reader
A updates
A releases lock
B get lcoks
B opens reader
B updates
B releases lock
The only way you can avoid this is if system can determine that B's
query results in the first case would not change based on A's updates.
On Jan 23, 2008, at 4:03 PM, Michael McCandless wrote:
robert engels wrote:
Thanks.
So all writers still need to get the write lock, before opening
the reader in order to maintain transactional consistency.
I don't understand what you mean by "before opening the reader"?
A writer acquires the write.lock before opening. Readers do not,
unless/until they do their first write operation (deleteDocument/
setNorm).
Was there performance testing done on the lockless commits with
heavy contention? I would think that reading the directory to
find the latest segments file would be slower. Is there a 'latest
segments' file to avoid this? If not, there probably should be.
As long as the data fits in a single disk block (which is
should), I don't think you will have a consistency problem.
Performance tests were done (see LUCENE-710).
And, yes, there is a file segments.gen that records the latest
segment, but it is used along with the directory listing to find
the current segments file.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
