Re: [hibernate-dev] Hibernate Search: configure the LockingFactory
2009/2/17 Hardy Ferentschik <hibernate(a)ferentschik.de>:
On Mon, 16 Feb 2009 15:06:27 +0100, Sanne Grinovero
<sanne.grinovero(a)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