[hibernate-dev] Infinispan DirectoryProvider for Hibernate Search
Emmanuel Bernard
emmanuel at hibernate.org
Thu Sep 30 04:08:22 EDT 2010
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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
More information about the hibernate-dev
mailing list