On Feb 18, 2009, at 11:49, Sanne Grinovero wrote:
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
s
On Feb 18, 2009, at 11:49, Sanne Grinovero wrote:
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 -> o
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 :
>
> On Feb 16, 2009, at 15:06, Sanne Grinovero wrote:
>
>> Hi al
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
opti
On Tue, 17 Feb 2009 10:23:28 +0100, Sanne Grinovero
wrote:
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 s
2009/2/17 Hardy Ferentschik :
> On Mon, 16 Feb 2009 15:06:27 +0100, Sanne Grinovero
> 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
On Mon, 16 Feb 2009 15:06:27 +0100, Sanne Grinovero
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 pro
