On Mon, 16 Feb 2009 15:06:27 +0100, Sanne Grinovero
1) property name:
I'm naming the property key "locking_strategy", scoped for each
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
At first I was planning to use the usual design to be able to specify
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
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
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
with H.Searche's design, so I am still trying to figure out if the
could be an option in case Search is the only process accessing the
Currently inside search the IndexReaders/Searchers are read-only, and at
one IndexWriter is using the DP, so the locking strategy could be set
to "none" IMHO.
If there is only one single Hibernate Search process running on the
no other process using Lucene natively it should be ok.
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?