On Jan 24, 2008 6:55 PM, robert engels <[EMAIL PROTECTED]> wrote: > Thanks, you are correct, but I am not sure it covers the complete case. > > Change it a bit to be: > > A opens reader. > B opens reader. > A performs query decides a new document is needed > B performs query decides a new document is needed > B gets writer, adds document, closes > A gets writer, adds document, closes > > There needs to be a way to manually serialize these operations. I > assume I should just do this: > > A gets writer > B gets writer - can't so blocked > A opens reader > A performs query decides a new document is needed > A adds document > A closes reader > A closes writer > B now gets writer > B opens reader > B performs query sees a new document is not needed > B closes reader > B closes writer > > Previously, with the read locks, I did not think you could open the > reader after you had the write lock. > > Am I correct here?
If I understand you correctly then yes and no :-) "Yes" in the sense that this would work and achieve the required serialization, and "no" in that you could always open readers whether there was an open writer or not. The current locking logic with readers is that opening a reader does not require acquiring any lock. Only when attempting to use the reader for a write operation (e.g. delete) the reader becomes a writer, and for that it (1) acquires a write lock and (2) verifies that the index was not modified by any writer since the reader was first opened (or else it throws that stale exception). Prior to lockless-commit there were two lock types - write-lock and commit-lock. The commit-lock was used only briefly - during file opening during reader-opening, to guarantee that no writer modifies the files that the reader is reading (especially the segments file). Lockles-commits got rid of the commit lock (mainly by changing to never modify a file once it was written.) Write locks are still in use, but only for writers, as described above. (Mike feel free to correct me here...)