lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pete Lewis" <p...@uptima.co.uk>
Subject Re: Lock handling and Lucene 1.9 / 2.0
Date Tue, 14 Sep 2004 09:40:34 GMT
Hi Konstantin

Yes, the current FSDirectory only really works well if you have a single
index on a system, otherwise it will cause problems.

After crashes we have a process to search and destroy any commit locks left
lying around in our indexes.

Cheers

Pete

----- Original Message ----- 
From: "Konstantin Priblouda" <kpriblouda@yahoo.com>
To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Sent: Monday, September 13, 2004 10:39 AM
Subject: Re: Lock handling and Lucene 1.9 / 2.0


> I'm also quite unhappy with FSDirectory and locking
> issues...
>
> Worst thing is that it creates locks on file system,
> and those files are not temporary. If JVM crashes for
> whatever reason - they are still there
> ( this is extremely inconveninet while debugging... )
>
>
> Another reasin is that it's in  no way friendly for
> IoC environment. It can not be created via
> constructor.
> Why?
>
> I had to write wrapper which delegates to FSDirectory,
> but this is not an elegant solution...
>
> It's not as unfriendly as hibernate ( for IoC via pico
> ) , but still unfriendly...
>
>
> > Therefore we dug in a bit more......
> >
> > Long answer - theres a heap of horrible, horrible
> > code in the FSDirectory that tries to be clever and
> > I think its not quite working correctly.
> >
> > Two types of lock - write.lock and commit.lock. The
> > write.lock is used exclusively for synchronising the
> > indexing of documents and has *no* impact on
> > searching whatsoever.
> >
> > Commit.lock is another little story. Commit.lock is
> > used for two things - stopping indexing processes
> > from overwriting segments that another one is
> > currently using, and stopping IndexReaders from
> > overwriting each other when they delete entries
> > (dcon't even start asking my why a bloody
> > IndexReader can delete documents).
> >
> > *However*, theres another naughty little usage that
> > isn't listed in any of the documentation, and here
> > it is....
> >
> > Doug Cutting wrote FSDirectory in such a way that it
> > caches a directory. Hence, if FSDirectory is called
> > more than once with the same directory, the
> > FSDirectory class uses a static Hashtable to return
> > the current values. However, if FSDirectory is
> > called with a *different* directory, it engages a
> > commit.lock while it updates the values. It *also*
> > makes that Hashtable (sychronised).
>
>
> =====
> ----[ Konstantin Pribluda ( ko5tik ) ]----------------
> Zu Verstärkung meines Teams suche ich ab Sofort einen
> Softwareentwickler[In] für die Festanstellung.
> Arbeitsort: Mainz
> Skills:  Programmieren, Kenntnisse in OpenSource-Bereich
> ----[ http://www.pribluda.de ]------------------------
>
>
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - 100MB free storage!
> http://promotions.yahoo.com/new_mail
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org


Mime
View raw message