[hibernate-dev] Configuration for Infinispan cache working as directory provider in HSearch

[Emmanuel Bernard]

On 18 août 09, at 17:35, Łukasz Moreń wrote:

> Now, every directory provider creates new Infinispan CacheManager -  
> factory for caches. Each manager creates cache with defined name.  
> Caches with this same name make distributed one, so we can have one  
> common cache, cache per directory, depends how they are named - that  
> way cache is shared. This is really not efficient since heavy  
> CacheManager is created with every indexed entity -  ideally one per  
> VM.
> The better idea I think is to share one CacheManager between all  
> directories in node.

OK

> Then shared are also caches objects locally - not like previously  
> every time is created new one.

I don't understand that sentence, can you detail a bit further.

> HSearch started twice, independently, that both instances don't  
> share resources - directories.? E.g. every time with different  
> configuration?

Yes, if you start HSearch twice, they should be totally independent  
(ie not share resources like CacheManager etc.

> To achieve that can be either created new CacheManager every HS  
> start, or used one, but with different cache names per app.

I like one CM per HS start but how do you think you can achieve that?

>
>
> 2009/8/14 Emmanuel Bernard <emmanuel at hibernate.org>
> How do you share the cache between different directories?
> A static field would not work well as it would prevent HSearch to be  
> started twice in a single app.
>
> Anyway if we share the cache, I would still like to use the per  
> directory provider configuration strategy (from a config property  
> point of view) and raise an exception if it turns out the Infinispan  
> cache config is different between two different indexes. That way we  
> can improve down the road.
>
> On 14 août 09, at 05:33, Łukasz Moreń wrote:
>
>> There is one cache for all indexes. In this case scoping  
>> configuration will be hard.
>> Yes, some default config will be provided. Right, different  
>> propterties for xml and programmatic would be better.
>>
>> 2009/8/14 Emmanuel Bernard <emmanuel at hibernate.org>
>> Question,
>> Do we have one cache for all indexes (directories) or one per  
>> directory?
>>
>> I feels wrong to see this configuration not scoped per index
>> hibernate.search.default.directory_provider  
>> blah.blah.InfinispanDirectoryProvider
>> hibernate.search.default.infinispan_conf com.acme.CacheFactoryImpl
>>
>> hibernate.search.Address.directory_provider  
>> blah.blah.InfinispanDirectoryProvider
>> hibernate.search.Address.infinispan_conf conf.xml
>>
>> hibernate.search.User.directory_provider  
>> blah.blah.InfinispanDirectoryProvider
>> hibernate.search.User.infinispan_conf auto
>>
>> As Sanne pointed out, maybe we want different properties for XML,  
>> programmatic and built-in configs. I kinda like the idea of one  
>> config but it seems it will be hard to differenciate a class from a  
>> config file.
>>
>> Emmanuel
>>
>>
>> On 13 août 09, at 18:33, Łukasz Moreń wrote:
>>
>> I was thinking that maybe we can expose full conf options.  
>> Infinispan supports programmatical and xml ways to configure cache.
>> To achieve first one, could be created some interface with factory  
>> method that returns cache. User can implement that and create cache  
>> as he wants.
>>
>> Something like that:
>>
>> <property name="hibernate.search.infinispan.conf"   
>> value="org.hibernate.search.store.infinispan.CacheFactoryImpl" />
>>
>> and for xml
>>
>> <property name="hibernate.search.infinispan.conf"  value="xml- 
>> conf.xml" />
>>
>>
>> Exposing some configuration to infinispan makes sense. can you  
>> start a thread explainig what is configurable and which one you  
>> think we should expose to hsearch users. Ideally I would like to  
>> offer one or two defaut config scenarios and allow to fallback to a  
>> custom config.
>>
>> Cheers,
>> Lukasz Moren
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090820/89dfe3e3/attachment.html