I think I just pushed the lock manager passed the breaking point. I'm
looking for ideas on how to fix it.

The lock manager has three primary functions:

1. Grant or deny lock requests, waiting if necessary
2. Notify a client when a lock it holds is blocking another client
3. Detect deadlocks after a suitable waiting period has expired.

A client in the original lock manager was an operating system level
process. A client was represented in the lock table as a "lock owner"
block, which contained whatever information necessary for another
process to wake it up, if necessary. Also in to the lock table was a
lock table header, a lock block, a request block representing a client's
interest in a lock, and a lock history block used for debugging. Lock
event notifications were performed by platform specific interprocess
communication.

The superserver conditional build extended the concept of a client to
include the database itself and a database attachment.

In the current lock manager, each client can have at most one pending
request. The deadlock scan code using the pending request to walk the
lock "wait for" graph to detect deadlocks. When a deadlock was
detected, a client was chosen to be victim and have its lock request denied.

The problem with all this is that it doesn't extended to threads at all
well. It held up reasonably ok for the serially threaded superserver,
but it doesn't hack it for Vulcan, which runs with fine grain threading.

The crux of the problem is the definition of client. If we want to
perform deadlock detection, anything that can block must be a client; in
specific a thread must be client (is this right?). But some locks
aren't held by threads. Things like relation existence locks really
belong to databases and/or attachments.

All that said, I haven't quite got my mind around how to do a deadlock
scan with a heterogeneous set of active (threads) and passive (object)
clients.

Any thoughts?

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376