On Mar 30, 2012, at 5:01 PM, Durchholz, Joachim wrote:

Thanks for explaining. If this is so, it sounds... unscalable.
How so?
You have to inflate your cache anew from DB in every transaction.
You don't have any data when you start.
Sure, that's unavoidable if you want to do optimistic locking.
However I don't think you are right in your assessment. Googling
"Hibernate second level cache" shows that its scope goes beyond
a single session.
Right... I was mislead by statements in other parts of the Hibernate literature I'm using.
That cache can be controlled on a per-table basis: switched off for data that never must be stale (financial records), switched on for read-only data (configuration etc.)
Quote Bauer/King: "... the second-level cache can be dangerous in systems that share the database with other writing applications." Hear, hear.

They have four levels
And hence my original question - how do they reconcile second
level cache presence and the promise of 100% data consistency.
It's the programmer's responsibility to decide what caching strategy to use for what table, it seems. They offer
- "transactional": cache only within a transaction (J2EE only)
- "read-write": detect stale data via timestamps
- "nonstrict read-write": no guarantees, use a timeout
- "read-only": cache is never updated

Second-level caches are pluggable, Hibernate can support EHCache, OSCache, SwarmCache and JBossCache. Not all caches support all strategies - maybe that's why I never considered that "a part of Hibernate".
My answer is that they don't. So their bigger argument about
data consistency is moot.
Well, Hibernate is a lot about high promises and 95% delivery :-)
Though, in this particular area, I don't think it's possible to do much better. If you want to be sure nobody altered data that you're not writing, you need to hit the database and have a rather scary performance penalty to pay. The only way out that I can think about that is that the programmer specifies all the data dependencies, including the implicit ones; then the ORM can restrict the staleness checking to those objects that the changed objects might depend on.
It would be the Right Thing To Do, but it would be hard to implement and fragile in practical usage, so I doubt it will be done.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 30 of 39 | next ›
Discussion Overview
groupuser @
postedMar 28, '12 at 8:27a
activeApr 10, '12 at 3:18p



site design / logo © 2022 Grokbase