Difference between revisions of "Locks and Deadly Locks"

From MidrangeWiki
Jump to: navigation, search
(Locks)
(Locks)
Line 14: Line 14:
  
 
Without locks, there is the danger that several programs might read in the data on some record into the program work area, change one or more fields, and be doing this concurrently with some other program.  Thus when one program writes copy of the data back to the file, with one field updated, the other programs still have copy of the data prior to this update, then when they write the data back with their field updated, the earlier program's update is lost.
 
Without locks, there is the danger that several programs might read in the data on some record into the program work area, change one or more fields, and be doing this concurrently with some other program.  Thus when one program writes copy of the data back to the file, with one field updated, the other programs still have copy of the data prior to this update, then when they write the data back with their field updated, the earlier program's update is lost.
 +
 +
One way that programs avoid this is to temporarily lock that which is to be updated until each program has done its thing, then release the record for other programs to access.  Normally program access, update, replace, is over in microseconds so users not notice this is going on.  However, sometimes we have poorly written programs, and users who get called away from their work station while they are in middle of an update program, so whatever record they were on is locked until they get back from the interruption, need to go to the bathroom, or lunch, or whatever.
  
 
== Deadly Locks ==
 
== Deadly Locks ==
  
 
'''Deadly Locks''' are a symptom of poor software design and/or poor implementation practices.
 
'''Deadly Locks''' are a symptom of poor software design and/or poor implementation practices.

Revision as of 15:32, 31 May 2005

Locks

Locks are normal.

GO CMDLCK

RPG reads an entire record into a program which will be updating the record on some account, item, customer, order, whatever. Different programs in the hands of different users might be updating different fields such as:

  • Inventory Totals
  • $ Financials
  • Alphabetical descriptions

We want to avoid conflicts between the different people who might be updating different fields in the same records at the same time.

Without locks, there is the danger that several programs might read in the data on some record into the program work area, change one or more fields, and be doing this concurrently with some other program. Thus when one program writes copy of the data back to the file, with one field updated, the other programs still have copy of the data prior to this update, then when they write the data back with their field updated, the earlier program's update is lost.

One way that programs avoid this is to temporarily lock that which is to be updated until each program has done its thing, then release the record for other programs to access. Normally program access, update, replace, is over in microseconds so users not notice this is going on. However, sometimes we have poorly written programs, and users who get called away from their work station while they are in middle of an update program, so whatever record they were on is locked until they get back from the interruption, need to go to the bathroom, or lunch, or whatever.

Deadly Locks

Deadly Locks are a symptom of poor software design and/or poor implementation practices.