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

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

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

> I believe my proposal avoids this problem by

> 1. Only caching stuff that came direct from a select. (important)

It does seem safer that way, but...

> 2. Never caching an instance until we know all updating transactions are
> finished

you can never know. The database has a lot of latitude, within the
isolation level model, to reorder things.

> You pointed out the problem that the select could return stale data, but
> it can never return data that was stale as of the start of the transaction.
> If we restrict it to only cache stuff that no-ones _begun_ to modify at
> any time _after_ the _start_ of the transaction, it can't possibly add
> stale data to the cache, right?

Well, we could also break transaction isolation in another way

T1 starts
T1 loads   obj1 v1
T1 caches  obj1 v1
T1 completes

T2 starts (obj1 v1)
T2 reads   obj1 v1      from cache

T3 starts (obj1 v1)
T3 updates obj1 v2
T3 commits obj1 v2

T2 updates obj2   (based on obj1 v1)          <<< error
T2 commits

The database didn't "see" T2 read obj1 since it came from the cache.
So the database can't know that T2 and T3 interfere, and T2 must be
rolled back.

> I think its possible to merge the good points of these proposals. So
> I'm very happy we are having this discussion.

Agreed.

I think version columns are the safest route.

e