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

Galder Zamarreno galder.zamarreno at redhat.com
Wed Aug 5 03:47:25 EDT 2009



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.

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

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



More information about the hibernate-dev mailing list