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(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>