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

[Brian Stansberry]

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.

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.

>>> 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?
> 
> 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