Deadlocks

In any system that manages shared resources, it is possible for deadlocks to occur. A deadlock is a standstill that is reached when two or more users are each waiting for a resource that the other holds.

In a CMS file pool, it is possible for deadlocks to occur only for implicit locks. Because the file pool server never waits for an explicitly locked object, even if FILEWAIT is ON, there cannot be a deadlock that involves any previously explicitly locked object—the server would have already terminated the request.

A deadlock would occur if USERA's program holds a lock on FILEA while waiting for a lock on FILEB. Meanwhile, USERB holds a lock on FILEB while waiting for a lock on FILEA. All the locks are implicit locks, obtained, perhaps, by opening a file for write. USERA is waiting for USERB, while USERB is waiting for USERA. If nothing was done, both USERA and USERB would wait forever.

Or, suppose user USERA's program holds an implicit lock on FILEA while waiting for an explicit lock on FILEB. Meanwhile, user USERB holds an implicit lock on FILEB while waiting for an explicit lock on FILEA, and both USERA and USERB have SET FILEWAIT ON. USERA is waiting for USERB, while USERB is waiting for USERA. This also would cause a deadlock to occur. If nothing was done, both USERA and USERB would wait forever.

The file pool server detects these situations when the deadlock is contained within a single file pool. The server resolves them by rolling back the youngest logical unit of work (the one that started most recently). The server will roll back the logical unit of work even if that user had entered SET FILEWAIT ON.

If you forget what locks you have created on your files, issue the QUERY LOCK command. The QUERY LOCK command also displays the locks created on your file by other users to whom you have granted read or write authority. You can also use the DMSOPDIR (Open Directory) routine with DMSGETDI (Get Directory) or DMSGETDK (Get Directory - Lock).