Re: [Hibernate] JCS cache - Distributable read-write

[Gavin K. <ga...@ap...>]

> --> The session hold a set of the items that have been updated/deleted in
the transaction,
> when the transaction commit, we iterate the set and remove each entry from
the cache.

but merely removing is not enough, because after removal, another
transaction (that started *earlier*) could come along and try to write stale
data in the cache because the database is actually free to return stale data
to a read operation. Thats the reason for the more complicated logic in
read-write cache. What you have to ensure is that a transaction that writes
to the cache _started after the completion_ of the transaction that removed
the object from the cache. (This is what the current read-write cache does.)

> With this logic, we end with a read only cache ( we never update an item
in the cache) for
> mutable objects.

I don't understand how this is different to the existing read-write cache
which actually doesn't allow *update* of a cached item, it only allows
removal from the cache when an object is updated.

There seems to be three types of cache:

Type 1:
you can add an item
you can't remove an item
you can't update an item

Type 2:
you can add an item
you can remove an item (when you attempt to update it on the DB)
you can't update an item

Type 3:
you can add an item
you can update an item (when you *know* you have updated its persistent
state)

Hibernate supports Type 1 (read-only) and Type 2 (read-write) but not Type
3. Type 3 would require Hibernate to know whether or not a transaction is
successful (which it doesn't, in general).

I'm not convinced that what you are implementing is different to Type 2
(except that it seems to have some holes...)