2009/2/17 Hardy Ferentschik <hibern...@ferentschik.de>: > On Mon, 16 Feb 2009 15:06:27 +0100, Sanne Grinovero > <sanne.grinov...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
