Deadlocks

A deadlock condition occurs when two users have to wait for each other in order to complete their respective transactions. For example, one user’s transaction needs records currently being used by a transaction started by another user. The second user’s transaction in turn requires records that the first user’s transaction is holding (while it waits for the second user’s transaction to be completed). Zim can detect deadlock situations and can abort the transaction of one of the users – the user’s updates are discarded, and locks released. The other user proceeds.

An application that normally responds very quickly, but is constantly deadlocking, is wasting its high performance. Deadlock situations are not errors, but rather the natural outcome of enabling more than one user to access the same data at the same time.

Completely eliminating deadlocks is not an acceptable solution. To do this, users are forced to wait in line to use the application. Operating system and application tuning can, however, reduce the likelihood of deadlocks, enabling the application, and its users, to maximize the amount of work done in a given period of time.

Page Locking

Zim uses automatic page locking to control concurrent access to the database. Locks force other users to wait until the user whose actions initiated the lock has finished using the data. This waiting can lead to deadlocks.

Two kinds of locks are used:

• a read lock on pages that are being read
• a write lock on pages that are being updated

A read lock enables other users to read the locked page; a write lock prevents other users both from reading and from updating the page.

Example

Two users, Bob and Macy, wish to access certain pages in a file at the same time:

• Bob wants to update page 5, and then read page 6.
• Macy wants to update page 6, and then read page 5.

Both users update their chosen pages successfully. However, Bob cannot read page 6 because Macy’s write lock precludes both updating and reading. Macy, on the other hand, cannot read page 5, because Bob has placed a write lock on it. A deadlock occurs because each user is waiting for the other. One user’s transaction (let’s assume Macy’s) is aborted, removing its page locks, and enabling the other user to continue. Macy’s work is lost.

File Locking

Zim can lock entire files (both read and write file locks) under certain conditions. A write file lock prevents other users from accessing any page in a file.

File locks can help reduce the incidence of deadlock. For example, Bob and Macy attempt the actions described under Page Locking, above, but, this time, file locking is employed.

When Bob updates page 5, a write file lock is placed on the file. Macy can neither read nor update pages 5 and 6. She must wait for Bob’s transaction to be completed before she can begin her own. Although waiting for Bob seems like a waste of time, this wait is better than the time wasted re-entering data after a deadlock.

Fine Tuning Locks

What the preceding example shows is that there is usually a trade-off between reducing the incidence of deadlock and maintaining a high degree of concurrent access to the application (several users accessing the database at the same time). In our example, file locking eliminated a deadlock, but it also reduced concurrent access (Macy had to wait for Bob). The administrator must  decide the level of trade-off that is appropriate for a particular application. A number of Zim Server configuration options can be used to fine tune the applications being serviced by Zim Server. The following must be considered before changing configuration options:

• All locks are maintained in memory by Zim Server. The operating system is not invoked to control any kind of locks managed by Zim Server. Therefore, the only limitation in configuring locks is the availability of memory;
• The locks configuration options are applicable to all databases being managed by Zim Server and not specifically to a single database or user.

All Zim Server configuration options documentation also discusses efficiency issues.

Of particular interest in the area of lock management are the configurations Maximum Locks, Maximum File Locks, Quick Locks, Secondary Lock Groups and Secondary Lock Group Size.