IBM Db2 - The Ultimate Database for Cloud, Analytics & Mobile
By Gareth Copplestone-Jones, Triton Consulting
As we saw in the previous article, (DB2 for z/OS Locking for Application Developers Part 1) the ACID properties of database transactions (atomicity, consistency, isolation and durability) are intended to guarantee data integrity. It’s important to emphasize that data integrity is a joint responsibility of the DBMS and the application programmer, and that this is the primary focus of this series of articles – a database without integrity has little business and informational value. The DBMS provides the mechanisms – from the point of view of this series, locking – to guarantee data integrity, but it’s absolutely necessary for the application program to code correctly for the locking strategy used. However, the locking mechanism (or locking semantic) has an impact on transaction concurrency – it slows transactions down and makes it harder to run them alongside each other, because of lock contention and lock wait suspensions. These two issues are discussed in more detail in a later article.
For now, this article concentrates on the basic elements of DB2 for z/OS locking semantics. A solid understanding of how DB2 for z/OS locks database objects – tablespaces, tables, pages and rows – is needed to be able to understand the data integrity implications of striking a balance between transaction isolation and transaction concurrency.
Add a Comment