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

[Galder Zamarreno]

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?

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

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.

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

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache