[hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
Brian Stansberry
brian.stansberry at redhat.com
Wed Aug 5 12:52:33 EDT 2009
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.
Moving beyond that, in the AS, w/ the AS impl of the JBC CacheManager I
was going to add capability to take a standard named config as a base
(e.g. "standard-session-cache") and then modify it to match
application-specified overrides (e.g.
<jboss-web><replication-config><buddy-replication>true</buddy-replication></jboss-web>)
I'd then generate a name for that config, and register it back with the
CacheManager for use, then use it to create a cache. I'd like to do the
same kind of thing with the Infinispan replacement of JBC's
CacheManager. Same kind of thing could be done in the Hibernate use
case for eviction.
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
More information about the hibernate-dev
mailing list