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 <emman...@hibernate.org>: > > 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 >> option to >> replace the default one in Hibernate Search. >> >> 1) property name: >> I'm naming the property key "locking_strategy", scoped for each >> DirectoryProvider. > > sounds good > >> >> >> 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. > > hum, does that makes our codebase more complex to support custom > LockFactories? I would like this flexibility/ > >> >> 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 > > yes, simple names for those that make sense and fqcn for the others. We > might also support a "factory" so that impl wo no-arg constructor can be > used, but that's an enhancement we can do later if needed. I avoided support for "fqcn" and factories to keep it simple; I'll add support for both for consistency and because you seem to like them. > >> >> >> 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? > > that sounds reasonable but how does that differ from > SingleInstanceLockFactory? the single instance locking has a java in memory lock, so to protect yourself in case of using several indexwriter/readers on the same index making changes when all running in the same JVM. 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 shooting at their own feet. As we are enforcing a single indexwriter and all our indexreaders are readonly since last release, you may want to use it: I think the current design of H.Search doesn't stop us from offering this option. I've added a note in the docs to use it only if you really understand it. > >> >> >> 4) default: >> The current default is "simple", which has the problem as reported in >> HSEARCH-284, >> so I was puzzled by the idea to define the "native" as the default one to >> have >> 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. > > OK > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
