cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: lazy loading (slightly OT but still pretty important)
Date Fri, 30 Mar 2012 13:48:27 GMT
Thanks for explaining. If this is so, it this sounds... unscalable. 

On Mar 30, 2012, at 4:45 PM, Durchholz, Joachim wrote:

>>> Hibernate strictly controls the staleness of objects. If a Session
>>> closes, the objects become detached and potentially stale, and
>>> there's no way to make the current again (except by transferring
>>> their contents to objects of a new Session). Hibernate goes to
>>> great lengths to protect that property.
>> I never used Hibernate, so this may be a dumb question, but how do
>> they reconcile this property with using a variety of object caches
>> in the framework?
> Hibernate has one entity cache per session.
> Its primary purpose is to have the original field values handy for UPDATE statements,
that's how they do optimistic locking:
>  UPDATE t SET f1 = :newvalue1, f2 = :newvalue2, ...
>  WHERE f1 = :oldvalue1 AND f2 = :oldvalue2 AND ...
> The statement returns the number of records changed, so if they get back a zero, they
know they have an optimistic locking conflict (and throw an exception, irrecoverably invalidating
the Session, grrr).
> This cache does not survive the Session.
> Hibernate itself does not have any more caches. That's why the Hibernate people recommend
using a DB cache underneath.

View raw message