Disabling locking is only recommended for read-only indexes that
aren't being modified. I think there is a comment in the code
about a good example of this being an index you read off of a
CD-ROM.
--- John Wang <[EMAIL PROTECTED]> wrote:
> Hi folks:
>
> My application builds a super-index around the lucene
> index,
> e.g. stores some additional information outside of lucene.
>
> I am using my own locking outside of the lucene index
> via
> FileLock object in the jdk1.4 nio package.
>
> My code does the following:
>
> FileLock lock=null;
> try{
> lock=myLockFileChannel.lock();
>
> indexing into lucene;
>
> indexing additional information;
>
> }
>
> finally{
> try{
> commit lucene index by closing the IndexWriter
> instance.
> }
> finally{
> if (lock!=null){
> lock.release();
> }
> }
> }
>
>
> Now here is the weird thing, say I terminate the process in
> the middle
> of indexing, and run the program again, I would get a "Lock
> obtain
> time out" exception, as long as you delete the stale lock
> file, the
> index remains uncorrupted.
>
> However, if I turn lucene file lock off since I have a lock
> outside it anyways,
> (by doing:
> static{
> System.setProperty("disableLuceneLocks","true");
> }
> )
>
> and do the same thing. Instead I get an unrecoverable
> corrupted index.
>
> Does lucene lock really guarentee index integrity under this
> kind of
> abuse or am I just getting lucky?
> If so, can someone shine some light on how?
>
> Thanks in advance
>
> -John
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
