[infinispan-dev] Hibernate Search alternative Directory distribution

[Emmanuel Bernard]

I am not sure I understand.
I assume that caches somehow have a unique identifier to recognize  
themselves in a cluster right?
So you have a CacheManager created on each node and by this "unique  
identifier", you can add a cache node to a given grid.

Infinitians, more infos?

On  Jul 15, 2009, at 11:05, Łukasz Moreń wrote:

> To have access to this same Infinispan cache on all nodes (master  
> and slaves) I have to create it from this same, single CacheManager.
> So there is difficulty how to distribute CacheManager to all nodes -  
> something like singleton in a cluster.
> Is there some recommended option how to achieve that in our case?
>
> Lukasz
>
> 2009/7/14 Emmanuel Bernard <emmanuel at hibernate.org>
>
> On  Jul 13, 2009, at 23:59, Manik Surtani wrote:
>
>>
>> On 13 Jul 2009, at 17:10, Łukasz Moreń wrote:
>>
>>> 1. share the same grid cache between the master and the slaves
>>>
>>> Infinispan has a flat structure. The key has to contain:
>>>  - the index name
>>>  - the chunk name
>>> Both with essentially be the unique identifier.
>>>
>>> I suppose in this idea all indexes are stored in a one single  
>>> grid. What about one Infinispan grid per directory, similarly to  
>>> RAMDirectory or FSDirectory? IMHO it could make some  
>>> simplifications i.e. in metadata or key names.
>>> Are there any Infinispan drawbacks to have a high number of caches  
>>> in the network? Sharing JGroups channels can help in that?
>>
>> They already share JGroups channels and other "heavy" components  
>> wherever possible.  Its just that configuration becomes more of a  
>> pain, etc.
>>
>> When you say one cache per index, how do you define an index?  Does  
>> 1 index mean all indexed data for a single java type?  In which  
>> case couldn't these scale up dynamically and potentially on- 
>> demand?  No wait - these are fixed in Hibernate Search on startup,  
>> correct?
>
> Right for now they are fixed at startup time.
> I'm unclear what is easier really. One cache or multiple caches.  
> Multiple configurations (if seen by the user) is a PITA on the other  
> hand could provide some flexibility (ie one cache behavior != than  
> another) but that's rarely needed very likely.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20090715/979e2705/attachment-0001.html