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.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

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



site design / logo © 2022 Grokbase