Thanks.
So all writers still need to get the write lock, before opening the
reader in order to maintain transactional consistency.
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.
On Jan 23, 2008, at 1:40 PM, Michael McCandless wrote:
robert engels wrote:
I guess I don't understand what a commit lock is, or what's its
purpose is. It seems the write lock is all that is needed.
The commit.lock was used to guard access to the "segments" file. A
reader would acquire the lock (blocking out other readers and
writers) when reading the file. And a writer would acquire the
lock when writing it.
If you still need a write lock, then what is the purpose of
"lockless" commits.
Lockless commits got rid of one lock (commit.lock), not write.lock.
You can get consistency if all writers get the write lock before
performing any read. It would seem this should be the requirement???
In Lucene, you use an IndexReader to do reads (not a writer), which
does not block other readers.
Is there a Wiki or some such thing that discusses the "lockless
commits", their purpose and their implementation? I find the email
thread a bit cumbersome to review.
No, but really the concept is very simple: instead of writing to
segments, we write to segments_1, then segments_2, etc.
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]
