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 I'll add this and the other conclusions to the JIRA and work on the asap. > > 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. > -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
