[hibernate-dev] Hibernate Search: configure the LockingFactory

Hardy Ferentschik hibernate at ferentschik.de
Tue Feb 17 04:01:09 EST 2009


On Mon, 16 Feb 2009 15:06:27 +0100, Sanne Grinovero  
<sanne.grinovero at gmail.com> wrote:

> 1) property name:
> I'm naming the property key "locking_strategy", scoped for each
> DirectoryProvider.

Is it really useful to be able to configure it per DirectoryProvider? How  
useful is it
to mix the locking strategies between providers?
I understand that from a consistency point of view it is the way to go. On  
the other hand
by providing all these options you bet that people will start using  
"stupid" combinations.

> 2) values:
> At first I was planning to use the usual design to be able to specify
> any implementation
> by specifying the qualified class name, but actually only 4
> implementations make sense
> and if someone really needed the flexibility to implement their own
> they can define
> their own DirectoryProvider and use whatever they want.
> Also 2 of the base Lucene implementations are missing a public no-args
> constructor,
> so I would use only simple names:
>
> simple -> org.apache.lucene.store.SimpleFSLockFactory
> native  -> org.apache.lucene.store.NativeFSLockFactory
> single  -> org.apache.lucene.store.SingleInstanceLockFactory
> none   -> org.apache.lucene.store.NoLockFactory

What's about a approach similar to "Reader strategy configuration", where  
shared and not-shared are
basically alias names for the underlying class names. This gives you names  
for the
most common lock factories and you can plug your own strategy.
And of course there is the consistency argument ;-)

> 3) support for "none":
> I don't think we should let the user select something which is not  
> compatible
> with H.Searche's design, so I am still trying to figure out if the  
> NoLockFactory
> could be an option in case Search is the only process accessing the  
> index.
> Currently inside search the IndexReaders/Searchers are read-only, and at  
> most
> one IndexWriter is using the DP, so the locking strategy could be set
> to "none" IMHO.
> opinions?

If there is only one single Hibernate Search process running on the  
machine AND
no other process using Lucene natively it should be ok.

> 4) default:

> Search beginners avoid the locking problem, but I am hitting some
> problems under load testing,
> so I think the default should stay to "simple" at least for now.

What are the problems?

--Hardy





More information about the hibernate-dev mailing list