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

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

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

I believe my proposal avoids this problem by

1. Only caching stuff that came direct from a select. (important)
2. Never caching an instance until we know all updating transactions are
finished

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

cool. Thats an improvement to what I had in mind.

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