> > * Allow LOCK TABLE tab1, tab2, tab3 so all tables locked in unison
Let me add to this. One problem is that my description would sometimes lock the tables in different orders, and
thatis a recipe for deadlock.
If you have to release earlier locks to wait on a later lock, once you get the later lock, you must release it and
thenstart from the beginning, locking them in order again. If you don't, the system could report a deadlock at
randomtimes, which would be very bad.
I'll add something, too. :) I think this derived from a suggestion I
made long ago. My idea was that when multiple tables need locking, a
deadlock can occur in the process of doing them one at a time. My
suggested solution was based on an analogy with the way ethernet
packets work.
- go through the list locking tables along the way.
- if a lock cannot be obtained within some time, release some (all?) locks, and try again after some random time.
- keep trying (and releasing as needed) until some other timeout passes, and then punt.
My thought was that if colliding locks are occuring, some sequence of
relinquishing locks (not necessarily all of them with each trial),
waiting, and reasserting them should work around the collisions.
Introducing random components to this might reduce the overall waiting
time, but I suppose a careful analysis of this needs to be done.
Perhaps just releasing all of the locks, waiting a random time, and
trying again is enough.
Somehow there has to be a mechanism for atomically asserting locks on
more than one table.
Cheers,
Brook