On Tue, 17 Feb 2009 10:23:28 +0100, Sanne Grinovero
I'm not really worried about "stupid" combinations as
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
with it without code changes); so this feature is really to provide
to have different ones per DP (and make is easy).
basically it looks like (IMHO) a bug in Lucene's implementation:
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
In this case we should definitely stay with 'simple' for now.