A method to remove locking conflicts
Original Publication Date: 2002-Apr-15
Included in the Prior Art Database: 2003-Jun-20
Existing locking semantics for Transactional systems all aim to protect against duplicate updates. They do this by locking an item. If this item is accessed by some other process, the lock prevents access. Thus, only a single process can be manipulating an item at once, so preventing the double update. Familiar processing does this locking at a file, database, record, row or Control-Interval basis. However, these locks cover a wider proportion of the item than may be necessary. For example, if you want to update a single field in a keyed record, then you lock the whole of the record, not just the specific field. The basic assumption is protect widely and then relax the scope as required. Locks are, in general, bad things as they prevent activity from occurring which could harmlessly proceed in parallel. They are good things, however, as they increase integrity. The problem to solve involves reducing the delay but retaining integrity. This can be solved by introducing an Intent Manager. Various logical techniques have evolved to reduce the lock time and so speed up processing. In the CICS/VSAM environment, a common technique is to have a counter in each record. When an update is PENDING, this counter is read and cached. When, later, the update actually happens, the counter is re-read: if it's the same then no intervening update has occurred so the current update can proceed otherwise the update is discarded. The upshot of this is that Locking prevents multiple updates (a good thing) but slows down activity (a bad thing).