[hibernate-dev] Hibernate Search: configure the LockingFactory

[Sanne Grinovero]

The issue is closed already:
http://fisheye.labs.jboss.com/browse/Hibernate/search/trunk
I'll add support to create LockFactories by fqcn later, I didn't
consider that important
at first.
answers inline:

2009/2/18 Emmanuel Bernard <emmanuel at hibernate.org>:
>
> On  Feb 16, 2009, at 15:06, Sanne Grinovero wrote:
>
>> Hi all,
>> to solve HSEARCH-284 (Lucene locks left around in application
>> restart/crash)
>> I am investigating the differences in all Lucene's LockFactory
>> implementations;
>> some of them are interesting and I would like to add a configuration
>> option to
>> replace the default one in Hibernate Search.
>>
>> 1) property name:
>> I'm naming the property key "locking_strategy", scoped for each
>> DirectoryProvider.
>
> sounds good
>
>>
>>
>> 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.
>
> hum, does that makes our codebase more complex to support custom
> LockFactories? I would like this flexibility/
>
>>
>> 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
>
> yes, simple names for those that make sense and fqcn for the others. We
> might also support a "factory" so that impl wo no-arg constructor can be
> used, but that's an enhancement we can do later if needed.

I avoided support for "fqcn" and factories to keep it simple;
I'll add support for both for consistency and because you seem to like them.

>
>>
>>
>> 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?
>
> that sounds reasonable but how does that differ from
> SingleInstanceLockFactory?

the single instance locking has a java in memory lock, so to protect
yourself in case of using several indexwriter/readers on the same index
making changes when all running in the same JVM.
The "none" doesn't protect at all, so you have to make sure to never open
a second indexwriter or use any indexwriter when you are using an indexreader
to make changes.
Sounds a bit dangerous IMHO but I don't think we should stop people shooting
at their own feet.
As we are enforcing a single indexwriter and all our indexreaders are
readonly since
last release, you may want to use it: I think the current design of H.Search
doesn't stop us from offering this option.
I've added a note in the docs to use it only if you really understand it.

>
>>
>>
>> 4) default:
>> The current default is "simple", which has the problem as reported in
>> HSEARCH-284,
>> so I was puzzled by the idea to define the "native" as the default one to
>> have
>> 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.
>
> OK
>
>