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]

Reply via email to