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

[Gavin_King/Cirrus%<CI...@ci...>]

> Here's an alternate design...

I have some questions:

> 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.

Q1.

the "commit time" would at best be a time "sometime after commit", unless
we did something awful like synchronizing around the commit(). So how would
you know which version actually represented the latest version in the
following:

(suppose isolation level is read committed or less)

transaction 1 updates foo
transaction 2 updates foo
transaction 1 commits
transaction 2 commits
transaction 2 grabs its timestamp
transaction 1 grabs its timestamp


> 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).

Q2.

I think I see part of your reasoning for "less than the session start
time", but could you please elaborate....

Q3. We still need to do the stale-check, right?

As I said to Doug in a private email, I've gone cold on the idea of
doing stale-checking using anything other than version numbers. The
performance cost is too high.... (i will elaborate in *this* later)

> - there is no synchronization, except to maintain the integrity of the
> data structure (i.e., no lock counts, etc.)

If by "sychronization" you mean blocking other threads, any proposed
solution _must_ obey this, far as im concerned.