Re[2]: [Hibernate-devel] caching algorithm

[Doug C. <de...@fl...>]

> aaahhhh of course. interesting. So we should use a timestamp from before
> the start of the session?

Here's an alternate design...

Maintain (potentially) multiple versions of objects in the cache, each
timestamped with the commit time of the writing session. The session
enters the object into the cache when the session commits. Sessions
can also enter objects at load time (on a cache miss) with the
timestamp set to the session start time.

Then any read simply takes (a version of) an object from the cache if
the object's timestamp is less than the session start time. Of course,
it must take the newest such instance (older than the session).

A hashbelt or similar technique can be used to delete objects from the
cache which have a newer instance which itself is older than all open
sessions.

This cache could be implemented with a Map of SortedSets.

The oldest open session could be implemented with a SortedSet.

It has the advantages:
- cached objects are only ever loaded once (updates are taken directly
from the writer session)
- a session always gets a cached object once that object is loaded
- nothing is ever removed from the cache except for expired obsolete
versions by hashbelt
- there is no synchronization, except to maintain the integrity of the
data structure (i.e., no lock counts, etc.)

e