[hibernate-dev] Re: [infinispan-dev] Hibernate Search alternative Directory distribution

[Łukasz Moreń]

Ah, Yes that's right, it's ok now.

W dniu 15 lipca 2009 17:22 użytkownik Emmanuel Bernard <
emmanuel at hibernate.org> napisał:

> 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/hibernate-dev/attachments/20090715/72167998/attachment.html