[hibernate-dev] Hibernate Search: configure the LockingFactory

[Sanne Grinovero]

2009/2/17 Hardy Ferentschik <hibernate at ferentschik.de>:
> 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.

I'm not really worried about "stupid" combinations as different DPs
are indipendent;
somebody could use a RAM-DP for something and a FS-DP for something else,
and maybe have one favourite on a NFS share.. for each one there are
more suitable locking strategies.
If you wanted to use only one strategy, then no code change is required
as Lucene is reading a system property to define the implementation
as you don't define one (and Search is not defining, so you could experiment
with it without code changes); so this feature is really to provide
the flexibility
to have different ones per DP (and make is easy).

>> 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 ;-)

Yes that's what I am proposing, the four names above is my proposal of
" simple name mapping to factories", to the implementations listed.

>
>> 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?

basically it looks like (IMHO) a bug in Lucene's implementation: it is
trying to acquire
the lock, if it's locked it tries again - only once - after a second,
and then it raises
a timeout exception if it fails again; even if the lock has been
available most of the time between the two checks.
I'll ask on lucene's forums if we could change that; anyway the
current 2.4 implementation is
not my favourite candidate for our "default" implementation;
I'm still investigating if my stress test was actually a situation
that's not occurring normally, we should have only
one thread (the writer one) accessing the index, but only in the "one
search instance per index" scenario.

>
> --Hardy
>
>

Sanne