Re[2]: [Hibernate-devel] collections

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

> What I have in mind is something *very* moderate. Basically my notion
> of caching is to allow sessions to use state loaded by a prevous session
> as long as everyone is only trying to _read_ the instance. As soon as
> some session wants to update it, we mark the instance uncacheable (in the
> cache) and force a return to the "normal" behaviour of hibernate.

This depends on user code telling the session of its intention to
modify an object before it's first read. Otherwise, if I have a shared
copy of something (i.e., from the cache) and decide I want to modify
it, how can you prevent modification from affecting other holders of
the object? The write "lock" has to be exclusive, and it can't be if
there are already readers.

The necessity of write-locking objects before reading them puts a
significant burden on the user code that didn't exist before. It can
also be the source of hard to locate bugs in application code. It's
why JDO has JDO-identity and class "enhancement" (mangling).

> sessions which got the object from the cache will need to update it
> using a stale checking update (above).

I don't see what problem this solves. I understand optimistic locking,
and it has its place, but it assumes every transaction has its own
copy of the object, not a shared copy from the cache.

>  Once we know the outcome of all updating
> sessions, we can mark the instance as cachable again.

A big synchronization bottleneck.

> This approach avoids redefining the transaction isolation level from how
> its defined by the database and still delegates all locking to the DB.
> Well, actually it would weaken serializable isolation, but i *think* it
> leaves repeatable read untouched.

Depending on the user code obeying the new write-lock (read with
intent to modify) rules. In any case it would break serializable
isolation.

> Do you see any obvious problems with this approach that makes it a waste
> of time?

We will probably all learn something!

Overall, it makes me queasy. I'd stick to (a) cache per session, or
(b) cache of read-only objects, and an error on any attempt to write
to one.

One extension to (b) is to provide a mechanism to evict something from
the cache so it can be written, but this means either waiting, or
failure, if there are any readers, which means you need reference
counts. It would also mean tracking evicted objects until they are
recached. All of this sounds an awful lot like locking!

e