> >From: Emil Briggs <emil@...>
>
> >OK. Now things are starting to make sense. I would argue though
> >that a process that holds a lock that it doesn't need is a bug
> >that needs fixing. Unless there is some other reason for doing it
> >that way?

From time to time I attempt to translate from Starkey to English,
and usually please neither the Starkey nor the English. Here is
one such attempt.

In the case of the classic architecture, each process keeps its
own cache. Every page in the cache of a process must hold a
read lock to announce that process's interest in the page.
Otherwise an updater could change the page in the database and
the process would have an invalid page in its cache and no
way to detect the problem. There are probably other ways to
implement it, but the crux is, when you want to change a page,
everyone else who has the page in cache must be notified.

In the superserver model, the cache is shared, so requests don't
express read (or write) locks.


Ann