On Oct 31, 2006, at 11:47 AM, Doug Cutting wrote:
I think the need for that would disappear if the lockless commit patch gets committed. Then there'd be no reason not to put lock files directly in the index directory, since only writers would need to lock things.
Unless the index is on an NFS volume. Then a Reader and a Writer can come into conflict because delete-on-last-close isn't supported. Some sort of read lock would be handy.
One possibility is to extend our file-based locking system to read locks by appending an integer increment to the lock-file name, so that we could tell how many readers were live by how many read-lock files were present.
Maybe we could have such files and compare modification dates against the incrementing segments.N files to identify which version of the index a Reader was opened against? Then, when it was time to delete files, the writer could discern which files were no longer needed and zap 'em.
One problem is that if a reader crashes, you don't get a fatal error -- the only effect is that the Writer just stops deleting files. Might be other problems, too, but I thought I'd throw the idea out there.
Marvin Humphrey Rectangular Research http://www.rectangular.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
