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 ma...@jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
