-
1. Re: JBossCache and readonly transactions
genman Apr 17, 2007 8:37 PM (in response to aricci)1) Caching read-only data is a good thing, is it not?
2) If it's a read-only transaction, why not replicate when data is fetched?
3) What's stored is up to Hibernate. What's replicated is up to JBoss Cache. To be honest, I don't really know, though. -
2. Re: JBossCache and readonly transactions
aricci Apr 18, 2007 4:15 AM (in response to aricci)Caching read-only data is a good thing if it is done locally, but i don´t understand why should we replicate them to all nodes in the cluster.
Scalability and good performances can be achieved only if we reduce the amount of informations sent to the channel. So imagine that a transaction performs a SELECT * FROM T, where T is a table containing 1.000.000 of records, this transaction would produce an incredible and not necessary traffic on the communication channel, decreasing scalability and performances of the all cluster. isn´t it?
Andrea -
3. Re: JBossCache and readonly transactions
jason.greene Apr 18, 2007 4:31 AM (in response to aricci)Please read the general hibernate documentation on the second level cache, as all JBossCache does is provide a replicated data store. Typically you lazily load a result set that large, unless you have massive amounts of memory.
-Jason -
4. Re: JBossCache and readonly transactions
brian.stansberry Apr 18, 2007 11:09 AM (in response to aricci)Still, it's a valid question. Even if we're only talking a single entity, the fact that node A read in the entity doesn't imply that node B wants to have it in memory. Replicating it takes resources.
For sure I don't see why we'd replicate this if the cache is in INVALIDATE mode rather than REPL. A quick look at the code in both HEAD and the 1.x branch leads me to believe we do. -
5. Re: JBossCache and readonly transactions
brian.stansberry Apr 18, 2007 5:29 PM (in response to aricci)For the issue of invalidating, see http://jira.jboss.com/jira/browse/JBCACHE-1027 .
If we could get INVALIDATE_SYNC working well for entities (i.e. stuff we're working on to allow a different cache for the query cache, which doesn't like INVALIDATE), then IMO the CacheMode attribute on the cache will provide sufficient control; i.e. if you want the entity to replicate when Hibernate caches it, use REPL_SYNC; if you don't, use INVALIDATE_SYNC. -
6. Re: JBossCache and readonly transactions
aricci Apr 19, 2007 6:05 AM (in response to aricci)- REPLICATION mode replicates everything is put inside the cache. This is bad because replicates everything, also objects that have not been modified, generating unnecessary traffic.
- INVALIDATION mode tags objects that are out of date. This is bad because objects have to be reloaded into cache accessing the database.
I think it would be better an hybrid approach: simply replicate changes.
Andrea -
7. Re: JBossCache and readonly transactions
genman Apr 19, 2007 1:22 PM (in response to aricci)
Andrea,
I agree that what or how things are replicated, cached, or invalidated should be entirely up to you. However, there are many valid reasons to replicate read-only data to all nodes of the cache. And there are just as many good reasons to use an invalidation strategy.
To label one approach as "bad" or not sounds really ignorant. -
8. Re: JBossCache and readonly transactions
brian.stansberry Oct 16, 2007 10:23 AM (in response to aricci)Andrea,
I just tested it, and for the head of the JBC trunk at least, setting a Option with setCacheModeLocal(true) before the putForExternalRead call prevents replication for that call. So, JBC exposes an API to allow the behavior you want.
If you want this behavior for Hibernate's use of JBC as a 2nd level cache, then you need to post a feature request on the Hibernate project. This could be controlled on a per-SessionFactory basis via a Hibernate configuration property. Configuring it on a per-entity type would be a lot more complex, if it's doable at all.