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

[Manik Surtani]

On 6 Aug 2009, at 08:21, Galder Zamarreno wrote:

>
>
> On 08/05/2009 06:52 PM, Brian Stansberry wrote:
>> Galder Zamarreno wrote:
>>>
>>>
>>> On 08/05/2009 04:04 PM, Brian Stansberry wrote:
>>>> Galder Zamarreno wrote:
>>>>>
>>> </snip>
>>>>>
>>>>
>>>> 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.
>>>
>>> Those names are not yet in use. They're just initial suggestions I  
>>> had
>>> in mind to map JBC2/3 cache integration to ISPN. Shortly after I
>>> realised that actually, for each entity/collection, a cache was  
>>> being
>>> created.
>>>
>>>>
>>>> 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.
>>>
>>> And I suppose that using those 4 properties follows the same kind of
>>> default pattern as previous cache integration layer which is a good
>>> thing.
>>>
>>
>> Cool. Being able to configure different caches per entity type will  
>> be
>> kinda nice.
>>
>> Semi-tangent: in general I really dislike if people have to configure
>> JBC/Infinispan to get standard behaviors (e.g. eviction). Much  
>> better if
>> people can use the standard configuration mechanism of whatever  
>> service
>> is using JBC/Infinispan, and only touch JBC/Infinispan configs for
>> exotic stuff. So, for example, web session passivation is  
>> configured via
>> jboss-web.xml, not via a JBC eviction region.
>>
>> If the properties needed to configure 2nd Level Cache eviction  
>> could be
>> reduced to 2 or 3, being able to express them via the SessionFactory
>> config would be nice, e.g.
>>
>> hibernate.cache.infinispan.Users.max_age=5000
>>
>> Perhaps just support LRU that way; if people want exotic stuff beyond
>> LRU they have to go to the Infinispan config.
>
> I like the idea a lot. This would limit the number of files to  
> modify for the most commonly touched things to 1 and that's a great  
> thing from a usability perspective. I think this is very doable as  
> well since ISPN has good support programmatic configuration (see http://www.jboss.org/community/wiki/infinispan-eviction)
>
> Infinispan has currently 5 settings in total for eviction/expiration  
> and so they're little enough that we support them all, i.e.
>
> hibernate.cache.infinispan.entity.strategy=LRU
> hibernate.cache.infinispan.entity.wake_up_interval=2000
> hibernate.cache.infinispan.entity.max_entries=5000
> hibernate.cache.infinispan.entity.lifespan=60000 // equivalent of  
> maxAge
> hibernate.cache.infinispan.entity.max_idle=30000 // equivalent of  
> timeToLive


Nice!


--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org