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

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

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

You wouldn't know (but it's no worse than the alternative, timestamp
at update time, is it?). In fact, even if you synchronized, you
wouldn't know: the database could order these transactions either way.
It's an example of why I've been queasy about this cache all along.

[Version info could be used to force (adjust) the order of the
timestamps.]

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

Well, if you are trying to get serializable transactions, you can't
see any modifications made after you've begun. If we allow reading
data written after session start, we've entered non-ACID territory.

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

I believe so, both because of Q1, and to protect against people trying
to use this across multiple JVMs.

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

Yes, I mean both thread synchronization, and cache "book keeping" or
locking to redirect loads to the database.

e