Galder Zamarreno wrote:
Hi,
Re:
https://jira.jboss.org/jira/browse/ISPN-6
Source code for this is currently located in an Infinispan branch in the
Hibernate SVN repo:
https://svn.jboss.org/repos/hibernate/core/branches/INFINISPAN/
http://anonsvn.jboss.org/repos/hibernate/core/branches/INFINISPAN/
I've picked this JIRA from Chris Bredesen. I'm waiting to get an answer
to an email I sent him yesterday but in the mean time, here's a list of
TODOs:
1. Current Infinispan region factory needs to point to a config with
named caches. Suggested property name: hibernate.cache.region.ispn4.configs
2. Need a equivalent version of this region factory where cache manager
is retrieved from JNDI. Suggsted property name:
hibernate.cache.region.ispn4.manager
3. Configuration properties for named cache names. Suggested property
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
4. Resolve TransactionalAccess, ReadOnlyAccess and BaseRegion TODOs.
5. Enhance query results region so that query changes are not propagated
if invalidation is used and add query.localonly equivalent property.
Suggested name: hibernate.cache.region.ispn4.query.localonly
6. Add more unit tests!
7. Document in wiki.
Some notes I've made while investigating this:
- Whereas with JBC2/3, we had the possibility of a shared cache for all
types (entities, collections, query,...etc) and a multiplexed version
where each type had a specific cache, in Infinispan, it only makes the
latter. Amongst other reasons because we don't have eviction regions any
more and so we can't exclude the timestamp modification region as we did
in JBC2/3. Overall, having a single option is a good thing from a
configuration and usability perspective! Remember how complex eviction
region definition could get for entities...
Is this basically a configuration issue? I.e. the eviction would have
to be configured via Hibernate SessionFactory properties, since the
Infinispan config file can't express it? That's unfortunate, as it means
different entity types can't have different eviction behavior.
The timestamps could be handled programatically; the Hib/Ispn
integration knows it's dealing with timestamps.
All that said, I have no problem with eliminating the possibility of a
shared cache. There is no legacy usage to support like there was with
JBC2. And if people want a shared cache, we can revisit.
Finally, a question to the list, specially for Brian/Steve who worked
on
the JBC2/3 integration layer:
- Do we need a similar timestamp region local cache implementation for
an ISPN based cache provider?
Sorry, I don't understand the question.
Cheers,
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat