Chapter16.Locking and Concurrency

Chapter 16. Locking and Concurrency

• Locking data

• Avoiding locks

• Claims and drains

• Locking issues and problems

• Designing for concurrency

It would be easy to have one process simply lock all the data while using it, but that, of course, would lead to other applications' being unable to access the data during this time. Concurrency, the ability for multiple applications to access the same data at the same time, needs to be allowed but also controlled in order to prevent lost updates, access to uncommitted data, and data changing between reads.

A balance must be achieved for maximum concurrency of all processes. Many controls in DB2 allow you to achieve maximum concurrency while maintaining data integrity. These controls range from the parameters for binding our programs with to options of the DDL for the creation of objects, to subsystem-level parameters.

DB2 uses locks to control concurrency within a database, that is, to manage simultaneous access to a resource by more than one user, or serialization. Locks also prevent access to uncommitted data, which prevents updates from becoming lost and allows a user to see the same data, without the data ever changing, within a period of processing called a commit scope. From a performance standpoint, everything done in DB2 has a tradeoff. In locking, the tradeoff is between concurrency and performance: More concurrency comes at a higher cost of CPU use, owing to lock management. In some cases, DB2 will override the locking strategy designed because processes hold locked resources exceeding the site-established thresholds. However, only certain combinations of parameters cause this to occur.