Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

A method to remove locking conflicts

IP.com Disclosure Number: IPCOM000015443D
Original Publication Date: 2002-Apr-15
Included in the Prior Art Database: 2003-Jun-20
Document File: 3 page(s) / 43K

Publishing Venue

IBM

Abstract

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).

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

A method to remove locking conflicts

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).

     This article claims that locking will always be necessary AROUND the physical I/O operation, but states that other locking can be done away with in favour of a different mechanism provided by an Intent Manager. This new mechanism will permit multiple updates to occur, and so increase activity. It does this by means of an event-driven mechanism to remove the need for locking.

     The basic idea is that an update operation (from an end-user viewpoint) can be decomposed into an Intent-step and an I/O step. The actual I/O operation requires the locking (and this submission does not propose to alter the semantics of this in any way) but the Intent-step does not. Existing function elides the two steps, and so locking extends for a longer period than necessary.

     Further, the Intent-step can be separated (in time/function) from the update step. Thus, for example, when an application starts running, it knows the Databases/Files it will want to access. Only after user input does the key/schema/row become known. It is this observation that this idea exploits. Consequently, when an user starts running the Application, we register the potential intent to update something. As time goes by, this Intent g...