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

Hi Emmanuel, thanks, some more comments inline: 2010/9/30 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > 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 You really mean the SessionFactory? we aren't integrating Infinispan that intimately to Hibernate right?

Assuming you meant the "SearchFactory", do you mean to pass an instance of Infinispan's CacheManager or shall we pass it a map of objects?

As you suggested below relating to the BuildContext, I like the idea of a Map<String,Object>, could we pass a similarly approached Map<String,Object> to the SearchFactoryBuilder ?

In this case we should internally track which services where provided and which where started in the factory, but then expose a single Map<String,Object> to the consumers:

I'll try defining a new interface, having something similar to the Map but wrapped in an object to keep track of some more details, like for each service if we should stop it or not. How is the eventual service going to be stopped? Should the same map be returned to the consumers at stop() time, so that -for example - the DirectoryProvider will care to stop the cachemanager it created? Or should each object in the map implement a "lifecycle" interface, so that a central stop method can stop all services.

Sanne > > 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 > >