Yes ... You've got it. However ... If I cant read the index while I'm updating it, then it doesnt help me much. This is a requirement. My architecture guarantees that the two machines maintianing the index wont work on the same index at the same time. But I have nothing that prevents the machines providing the search from reading the index at the same time as it is being updated by the other machines.
So it sounds to me like I still need to use the Lucene locking. And it also sounds like I need set the "Lock Directory" to be in the shared location where I'm keeping the index directory. Because currently each machine is using its own "Lock Directory" ... which I guess means that the search isnt currently locked against the writes now. So if my indexes are located here: \\server\indexes\index1\ \\server\indexes\index2\ I should set the "Lock Directory" for ALL the machines to be something like: \\server\indexes\lockdir\ Make sense? Andy On 11/1/06, George Aroush <[EMAIL PROTECTED]> wrote:
Hi Andy, So two machines all that they do is update the index, and they are synchronized, right? Then you have two other machines that provide search, right? And your 4th machine simply hosts the index. Did I get this right? Sure, the search machines can be set as read-only, but they can't read an index while it is being updated. If you are preventing this, then you are all set. Regards, -- George Aroush -----Original Message----- From: Andy Berryman [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 9:34 AM To: [email protected] Subject: Re: Setting "disableLuceneLocks" to "true" for Read-Only Mode As for the architecture of my project currently ... Think about it as involving 5 machines. 1 machine hosts the UNC share folder that contains the index directory. 2 machines run an NT service that looks for changes in the database and then uses the "Reader" to delete documents and then the "Writer" to add documents. These machines synchronize their work such that they each arent working on the same index at the same time. 2 machines run a web service that provides methods to search the index and return results. As such ... the machines that run the Web Service have NO path that involves manipulating the index at all. Therefore, I was thinking that disabling the locking on those machines would simply reduce to extra overhead that doesnt really seem necessary for me. Thoughts? Thanks Andy On 11/1/06, George Aroush <[EMAIL PROTECTED]> wrote: > > Hi Andy, > > If you have your own solution to guarantee reader/write locking, and > it's faster then what Lucene.Net has to offer, you can use it. > > "disableLuceneLocks" is provided by Lucene.Net so that a Lucene > application can be run off a CD/DVD (read-only device) thus, no lock > file will be created. > > BTW, what is your solution? > > Regards, > > -- George Aroush > > -----Original Message----- > From: Andy Berryman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 31, 2006 4:23 PM > To: [email protected] > Subject: Setting "disableLuceneLocks" to "true" for Read-Only Mode > > What are the benefits of doing this versus just letting Lucene do its > normal locking when set to "false"? I have a scenario where I can > gurantee that the processing using the Reader object is ONLY going to > read the index and NOT modify it in any way. It seems to me that > disabling the locking would reduce some overhead that I dont really > need to care about. > > Thoughts? > > Thanks > Andy > >
