[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:40 PM, Brian Stansberry wrote:
>> Galder Zamarreno wrote:
>>>
>>>
>>> On 08/04/2009 06:23 PM, Brian Stansberry wrote:
> 
> </snip>
> 
>>>>
>>>> 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.
> 
> Ok, so they need to be kept in separate cache instances then. Thx.
> 
> </snip>
> 
>>>>>
>>>>>> 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?
> 
> No, that's not there yet. At the moment, we simply take the region name 
> that we're passed (this defaults to entity type FQCN) and we look up a 
> cache from cache manager with that name.
> 

Sounds like this has diverged quite a bit from the JBC integration then. 
In your initial message you were discussing names:

hibernate.cache.region.ispn4.cfg.entity
hibernate.cache.region.ispn4.cfg.collection
hibernate.cache.region.ispn4.cfg.query
hibernate.cache.region.ispn4.cfg.timestamps

What were those to be used for?  With JBC they identify the name of a 
cache configuration, which is used to obtain an appropriately configured 
org.jboss.cache.Cache from the JBC CacheManager. My assumption on this 
thread was the same basic approach would be used with Infinispan. The 
"region name" that Hibernate passes is not meant to be the name of the 
cache configuration. It could be a unique identifier for the cache 
that's created using that configuration, but it's not the name of the 
configuration.

If you follow that approach, you use the above properties to establish 
defaults for each of the 4 data types. You then use the techniques you 
discuss below to override those defaults if people need specialized 
configs for certain entities.

> Having had a thought overnight to this, I do see the point of having 
> that mapping though, otherwise if you have 10 entities which cache 
> settings A and 10 entities with cache settings B, we'd be needing to 
> implement 20 cache definitions. See below for a further discussion on 
> your suggested mapping.
> 
>>
>>> 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.
> 
> To make sure I understand this correctly, the way I see this is the 
> following. Assuming we have two entities: com.acme.Person and 
> com.acme.Address and Person has a List of addresses represented by 
> com.acme.Person.addresses:
> 
> If no region name was configured, the provider would retrieve a cache 
> using the default region names given and these are:
> com.acme.Person
> com.acme.Address
> com.acme.Person.addresses
> 
> If region names have been configured but there're no overrides like the 
> ones suggested by Brian, use simply the region names passed to get the 
> caches from the cache manager.
> 
> At startup, if overrides similar to this had been defined, then the 
> overrides take over and a cache with name NoEvictionCache is looked up 
> when building the region:
> hibernate.cache.infinispan.com.acme.Person.cfg=NoEvictionCache
> hibernate.cache.infinispan.com.acme.Address.cfg=NoEvictionCache
> hibernate.cache.infinispan.com.acme.Person.addresses.cfg=NoEvictionCache
> 
> These overrides could have been defined using user-defined region names 
> in which case the RegionFactory build* callbacks would be passed these 
> and would be applied in the same way.
> 
> Finally, wrt query/timestamps region names, by default, these appear to 
> be hardcoded to org.hibernate.cache.UpdateTimestampsCache and 
> org.hibernate.cache.StandardQueryCache. However, having had a look at 
> the code, both UpdateTimestampsCache and StandardQueryCache, could have 
> a cache region prefix configured, so my initial idea of simply using 
> their FQCNs as cache names might not always work. So, we do need some 
> properties here too:
> 
> hibernate.cache.infinispan.cfg.timestamps=UpdateTimestampsCache
> hibernate.cache.infinispan.cfg.query=StandardQueryCache
> 
> Then we'd have caches names with UpdateTimestampsCache and 
> StandardQueryCache.
> 
>>>>>
>>>>>>
>>>>>> 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