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 docloses, 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.
they reconcile this property with using a variety of object caches
in the framework?
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.
