Re: [hibernate-dev] Infinispan DirectoryProvider for Hibernate Search
As usual thanks for the deep analysis.
I've been looking at this problem and here is where I am.
Lifecycle
1. You pass an instance to the SessionFactory in which case you're responsible for the
lifecycle
The instance passed needs to be passed to the next ImmutableSearchFactory if a
reconstruction due to class addition occurs
2. You can ask the SearchFactory to instantiate the object at startup and destroy it when
closing
Once created, the object should be kept to be passed to the next ImmutableSearchFactory if
a reconstruction due to class addition occurs
We need a way to register this new type of Lifecycle implementation
The lifecycle implementation should pass the Properties instance to leave it configurable
To expose this Map<String, Object> (instances generated by the lifecyle logic) to
DirectoryProviders, as you said, using the BuildContext sounds appropriate. We should also
make it part of StateSearchFactoryImplementor, this is how we will be able to pass them
from one ImmutableSearchFactory to another. We also need to keep the lifecyle object
themselves to be able to call the destroy operation on SF.close();
Is that a bit clearer?
On 16 sept. 2010, at 18:52, Sanne Grinovero wrote:
Hi all,
this was planned long time ago and is now being requested often,
especially on the Infinispan forum and irc.
As Search might have to manage several indexes, these can all be
stored in the same cache, or in different caches;
In both cases the cache or CacheManager should be reused, and so the
different DirectoryProvider implementations should
be able to get a reference to the CacheManager.
In case this is stored in JNDI, this should be trivial, but when it's
not we might need to manage the CacheManager lifecycle and
have a global configuration file for it.
The Infinispan Directory was designed to work with Search, so it's all
about dependencies and configuration; these are the steps needed:
1) create a module
- needed to introduce the Infinispan dependency and Java6.
- it could be loaded using the FQN for the moment, and later on we
could think about a SPI to plugin "short names"
2) define how a single Infinispan CacheManager's lifecycle should be
handled when JNDI is not used
[as noticed here: http://community.jboss.org/thread/155875]
- The initialize(..) method of the DirectoryProvider should pass a
reference to a started CacheManager,
I see we have now a BuildContext passed in, could we use this to
pass a reference to a loosely coupled CacheManager?
- the SearchFactory should start a cacheManager before the DirectoryProviders
- it should stop the cachemanager
- we should enable a configuration property to name the Infinispan
configuration file
3) In case JNDI is used, provide needed configuration for it (name?)
This provides a usable distributed index, but then other components
should be integrated:
* Share the cachemanager used for the index with the one eventually
setup as second level cache
* Share Infinispan's JGroups channel with the JGroups backend of
Hibernate Search to setup master/slave configurations
* Share Hibernate's database as a cachestore for the index
I'm in need of ideas about how to integrate the lifecycle of the
CacheManager, if someone could help on that I could assemble some of
the other pieces.
Cheers,
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev