On 1 oct. 2010, at 14:14, Sanne Grinovero wrote:
> Hi Emmanuel,
> thanks, some more comments inline:
>
> 2010/9/30 Emmanuel Bernard <emman...@hibernate.org>:
>> 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?
SearchFactory sorry.
>
> 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?
something liek builder.addStuff("infinispan", cacheManager);
this is backed by a Map internally
> 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 ?
yes, see my comment above
> 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:
yep
> 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.
yes the latter seems better and more flexible to me: whoever starts it, stops
it.
>
> 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@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
