[hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions

[Brian Stansberry]

Galder Zamarreno wrote:
> 
> 
> On 08/04/2009 06:23 PM, Brian Stansberry wrote:
>> Got distracted and hit send early last time...
>>
>> Brian Stansberry wrote:
>>> Manik Surtani wrote:
>>>>
>>>> On 4 Aug 2009, at 14:02, Galder Zamarreno wrote:
>>>>
>>>>>>
>>>>>> s/region.ispn4/infinispan
>>>>>
>>>>> Ok.
>>>>>
>>>>> One thing here though. Chris's original solution works in such way
>>>>> that for each entity/collection, a new cache is retrieved from the
>>>>> cache manager using the region name, so for this example 3 caches
>>>>> would be created:
>>>>>
>>>>> Cache1 for
>>>>> [org.hibernate.test.cache.infinispan.functional.VersionedItem]
>>>>> Cache2 for [org.hibernate.test.cache.infinispan.functional.Item]
>>>>> Cache2 for [org.hibernate.test.cache.infinispan.functional.Item.items]
>>>>>
>>>>> Can we confirm this is the intented way? In
>>>>> https://jira.jboss.org/jira/browse/ISPN-6 the following is mentioned:
>>>>>
>>>>> "Use a separate named cache per entity. This cache would hold entity
>>>>> instances as well as collections pertaining to that entity."
>>>>>
>>
>> In the JBC2 integration, the JBC Region is pretty important, beyond
>> eviction. There are things like clear operations that are scoped to the
>> Region (e.g. to support invalidating all entities of a given type out of
>> the cache). The Infinispan integration will have the same use cases, and
>> AIUI a cache is the semi-analogue to a JBC Region, so I think you need a
>> cache per entity type.
> 
> + 1
> 
>>
>> Also, unless there's a really good reason not too, let's try to keep
>> things logically the same between the Infinispan and JBC integrations.
>> Makes maintenance much easier.
> 
> Assuming that org.hibernate.test.cache.infinispan.functional.Item.items 
> is a Collection belonging to 
> org.hibernate.test.cache.infinispan.functional.Item, do you agree on 
> keeping each in a separate cache?
> 

Yes. With JBC they are separate Regions. We need the ability to scope 
things like clear commands to the data hibernate is working with, and an 
entity and its associated collections are separate things to hibernate.

>>
>>>>> So, if that is followed and we bear in mind the above example, there
>>>>> should only be 2 cache instances created rather than the current 3.
>>>>>
>>>>> What is clear is that there's no need for
>>>>> hibernate.cache.infinispan.cfg.entity or
>>>>> hibernate.cache.region.ispn4.cfg.collection. Simply stick the
>>>>> default cache configuration for entity/collections in the default
>>>>> section of configuration.
>>>>>
>>>
>>> Yeah, I've never found a good use case for using different configs for
>>> the two. Perhaps eviction
>>>
>>>>> I don't we need hibernate.cache.infinispan.cfg.query and
>>>>> hibernate.cache.infinispan.cfg.timestamps either since we can simply
>>>>> name the caches with the corresponding region names
>>>>> (org.hibernate.cache.UpdateTimestampsCache]and
>>>>> org.hibernate.cache.StandardQueryCache) and that's it.
>>>>
>>>
>>> The hibernate.cache.infinispan.cfg.query and
>>> hibernate.cache.infinispan.cfg.timestamps properties aren't used to
>>> name the caches. They specify what config to use.
>>>
>>>> I suppose that would depend on the need for different eviction
>>>> characteristics for different entity types. So from that perspective
>>>> (the ability to use) a different cache per entity is useful.
>>>>
>>>> E.g.,
>>>>
>>>> NoEvictionCache for [CountryList]
>>>> NoEvictionCache for [SomeOtherDropDown]
>>>> AggressivelyEvictedLRUCache for [Users]
>>>> AggressivelyEvictedLRUCache for [Orders]
>>>> LargeCapacityFIFOCache for [ProductsCatalog]
>>>>
>>>> etc. may well prove useful. Brian/Steve - care to chime in?
> 
> No, we haven't lost it at all. You can define a cache with specific 
> eviction settings and give it as name the FQCN of the entity and that's 
> done.
> 

How is this configured by the end user? I mean the mapping from the 
entity type to the cache config name. Is something like what I described 
below implemented already?

> The problem though is that for each Collection this entity has, you'd 
> need a separate cache instance since at the moment, an entity's 
> collection is stored in a separate cache.
> 
> So, if Person has several Address instances, Person will be one cache 
> instance and his/hers addresses would be stored in a different cache 
> instance.
> 

True. Although this is only an issue if you wanted separate eviction. 
Hibernate allows you to specify a region name for any cachable item 
(except timestamps).  The use of FQCN is just a default for people who 
don't want to configure things.

>>>
>>> hehe, I kinda just somewhat did on another branch of the thread. W/
>>> JBC, different eviction per entity type could be configured via the
>>> JBC config, using eviction regions. Seems we've lost that, unless
>>> SessionFactory properties are added that tell the RegionFactory what
>>> Infinispan config to use on a more fine-grained basis than "entity",
>>> "collection", "query", "timestamp". This could perhaps be done by
>>> using "entity", "query" as default values and allowing
>>> replacement/extension to override the default for a particular region
>>> name.
>>>
>>> hibernate.cache.infinispan.CountryList.cfg=NoEvictionCache
>>>
>>> The ugly bit is that works if people configure a region name for their
>>> entities, rather than using the default fully qualified class name. I
>>> suppose the fully qualified class name could work as well, just a bit
>>> more parsing.
>>>
>>>>
>>>> Cheers
>>>> -- 
>>>> Manik Surtani
>>>> manik at jboss.org <mailto:manik at jboss.org>
>>>> Lead, Infinispan
>>>> Lead, JBoss Cache
>>>> http://www.infinispan.org
>>>> http://www.jbosscache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat