At 02:39 PM 3/24/00 -0500, Emil Briggs wrote:

>From: Emil Briggs <emil@...>
>
>
>Keeping the pages used by the lock table in RAM should be easy to
>do with mlock. I'm curious about how the lock manager works for
>classic since being able to run on a cluster would be a big plus
>for certain applications. So with the disclaimer that I havn't
>seen the source code yet and don't know how things are implemented
>in the classic architure let me ask a few (possibly naive) questions.
>
>1. I assume that each process spawned from inetd communicates for
>locking purposes via some form of IPC? If this is Sys5 IPC then
>a package like DIPC should make a distributed version easy to
>implement (performance might be lousy of course but for a read
>mostly database that might not matter).
>
>2. Is there any high level description of how the lock manager
>works in classic available anywhere? (I know we'll have answers
>to these questions when the source is released).
>

Interbase "classic" is designed to run in the user process
context. It is a shared library. It syncronizes access to
pages with a lock manager.

An Interbase server is a process that listens to the network
and talks to a local Interbase. Interbase doesn't know that
it's a server. Depending on start up switches an Interbase
server serves a single client (started on demand by inetd)
or an be long lived, serving multiple clients. The latter
architecture works better on multi-threaded platforms where
the server can thread switch to avoid monopolization by a
single client.

The Interbase lock manager is semantically identical to the
VMS lock manager (it uses the VMS lock manager when running
on VMS). The lock manager support shared read, shared write,
protected read, and protected write modes, and can give a
lock holder an asynchonous trap (AST) when somebody else
starts a wait on the lock. Small quantities of infomation
can also be stored with a lock to provide fodder for abuse.
The lock manager is responsible for detecting deadlocks.

Interbase (and its precursor) were originally designed to work
on VAXClusters. Given an appropriate distributed lock manager
and appropriate file sharing semantics, Interbase would work in
any cluster environment. These are non-trivial requirements.

A true distributed lock manager is a very difficult piece of
code to write. The only one I know of was written by Steve
Beckhardt (now president of the Lotus's Notes subsidiary);
DEC stopped trying to add features when he left the company.
Among the hard parts are high performance distributed deadlock
detection, node failover, nodes joining the cluster, and extremely
low latency lock requests. Probably more hairly than the Linux
kernal.

High personal shared files are also a problem. Unless the
various cluster members are in serious cohoots, it precludes
disk caching. For high end disks, DEC used unusually bright
disk controllers that understood clusters. Cheap disk required
that cluster member emulate cluster controllers with local
disks. Linux (and most Unixes) would probably take a great
deal of work to ensure that at the time a process level
write completes that page can be safely fetched on another
code on the cluster. A really dumb cluster design would make
this easy, but would also make the cluster useless.

Most cluster architectures are hacks to support cooperative
computation (parallel computing) and are unlikely to have
the depth to support database server clusters.

Jim Starkey