cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Durchholz, Joachim" <>
Subject RE: lazy loading (slightly OT but still pretty important)
Date Fri, 30 Mar 2012 14:37:13 GMT
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.

View raw message