Re: Re[2]: [Hibernate-devel] collections

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

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

Ah...theres one more element to this. We _copy_ things in and out of the
cache. sessions still have their own instances (always). The only
point of the cache is to eliminate some sql select statements. I
should have made this clearer.

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

yes I don't want to force applications to do a loadForUpdate() .... if
this can't be done transparently, it shouldn't be done at all.

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

exactly. they have a copy of the cached state.

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

> A big synchronization bottleneck.

not that big. keep a counter in the cache. at the completion of each
session decrement the counter and when it hits zero, we can start
caching that instance again. (have a look at the code in CVS)

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

absolutely it will weaken serializable (to repeatable read, I *think*).
If it weakens the isolation further than this, I am happy to drop
the whole idea....

(It certainly doesn't weaken read committed.)

but think about the situations where this kind of caching is useful:

1. static data
2. 'timeout data'
3. data which is rarely updated (=> concurrent updates even rarer)

these are not the kinds of scenarios where we need serializable
isolation.

Anyway, the cache is configured on a class-by-class basis, so if it
will be a bad thing, don't use it.

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

> We will probably all learn something!

no doubt.

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

I *am* inclined towards agreement here. Nevertheless, I would like to
give the implementation i've come up with a chance to prove itself.
I may have a completely flawed concept here and theres something
im not seeing. If so, im happy to drop it.

At present everything except collections are cached. Its been possible
to do this without major changes to existing code. (the changes I
*have* made are useful for other reasons and can be defended on that
basis.) To cache collections *will* require changes.

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

this again assumes we actually share an object instance between sessions.
I doubt very much that it would be possible to do this without totally
rewriting hibernate. All code assumes that objects are non-shared.

thanks for your input - it is very needed

Gavin