lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Berryman" <topd...@gmail.com>
Subject Re: Setting "disableLuceneLocks" to "true" for Read-Only Mode
Date Wed, 01 Nov 2006 14:34:06 GMT
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 <george@aroush.net> 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:topdev1@gmail.com]
> Sent: Tuesday, October 31, 2006 4:23 PM
> To: lucene-net-dev@incubator.apache.org
> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message