lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doron Cohen <DOR...@il.ibm.com>
Subject Re: Lock-less commits
Date Sat, 26 Aug 2006 01:49:42 GMT
> I think that because of NFS caching thats only true when a1 and
> a2 deal with the same file -- i could be wrong however.  If i'm right
then
> your proposal suffers the same problem (another client might see all of
> the changes you've made to the version file and think the index is in a
> consistent state, but not realize that the file is a stale cached file.

I don't know better than that, so let's assume that no order is guaranteed
between operations on different files. I can see that in this case my
version-file logic would fail.

How about the numbered-files approach - would it work under this
assumption? Say a writer wrote a new version, and at just the end of that
wrote the appropriate segments file. A reader doing Directory-list would
see the segments file of recent version N but might not yet see all the
required index files for version N.

I now think this is already addressed in this thread by having the reader
know exactly which files are required to exist, and having the writer
always creating all files, possibly as empty files.

Under this no-order assumption, it is also possible that a file exists but
only part of it is available for the reader - to defend against this the
reader should be able to verify that the segments file is complete, and
that each of the other files is complete - using the file length or so,
right?

> I'm not saying your proposal is bad -- just that i don't think it will
> solve all the problems you think it will solve.

No problem, I already agreed with that.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message