[hibernate-dev] Hibernate Search: Infinispan DirectoryProvider

[Sanne Grinovero]

Inline:

2010/3/9 Emmanuel Bernard <emmanuel at hibernate.org>:
>
> On 9 mars 2010, at 12:47, Sanne Grinovero wrote:
>
>> Hi all,
>> I'd like to merge the Infinispan DirectoryProvider soon:
>>
>> The code is trivial as it was designed primarily for Search, but some
>> points need to be discussed:
>>
>> 1) Dependencies
>> 1A) Transaction implementation:
>> It does require Infinispan modules, most are transitive dependencies of
>>   <groupId>org.infinispan</groupId>
>>   <artifactId>infinispan-lucene-directory</artifactId>
>>
>> but it also requires a transaction manager implementation, which is
>> not enforced by infinispan as any implementation will do.
>> Shall we "suggest" one as optional dependency?
>> This is going to add many dependencies, but we need something at least
>> for tests.
>
> I'd mark it provided or something like that? What is the strategy that the Infiniboys use for their tests?
>

In Infinispan dependencies like jbossjta are in test scope while the
jboss-transaction-api is in compile scope;
fine for me, I'm just warning that without modularizing Search this is
going to introduce many additional jars.

>>
>> 1B) JGroups
>> Infinispan depends on newer JGroups version than the one currently
>> tested by the jgroups backend. I'd expect the new version to work the
>> same, but are we going to explicitly depend on the same version of
>> Infinispan?
>
> +1, we probably need to use what Hibernate Core is using, ie a central place to declare deps for all HSearch "modules"
>
>>
>> 2) Infinispan initialization
>> A single CacheManager should be shared across many caches; in practice
>> while I'd suggest to use a different cache per index we even do
>> support more than one index in the same cache.
>> At least a configuration property would be needed to point the
>> CacheManager initialization to an Infinispan configuration file -
>> which in turn will lilkely point to a JGroups configuration file.
>> This configuration property could be global or "directory scoped" like
>> we do for other properties but that would be complex.
>>
>> I'd suggest a single global CacheManager configuration - which will
>> trigger a CacheManager initialization in the SearchFactory - and have
>> different Directories be able to select the cache name and index name
>> they want to use;
>> (If two directories use the same cache and same index name they are
>> sharing the same index)
>> It would look like:
>>
>> hibernate.search.infinispan_configuration lucene-cluster-conf.xml
>> hibernate.search.default.directory_provider
>> org.hibernate.search.store.InfinispanDirectoryProvider
>> hibernate.search.default.cache_name defaultLuceneIndexes
>> hibernate.search.Animal.cache_name AnimalsLuceneIndex
>
> Looks good but it means we need some kind of lifecycle hook for this cache manager to be initialized in Hibernate Search before the directory providers.
> For example it would be nice to pass the properties to this initializer hook and let it decide whether or not it needs to do something on SF init and on SF close. These hooks could be discoverable or example by using the service pattern.

I'm not sure about which pattern, do you have an example ? google
found several different things all generically named "service
pattern".