This article written by Will Johnson, for Fast Forward Technologies. Email me at fft2001@aol.com
See also the Pick Operating System Portal
See also the Pick Operating System Portal
[Edit]
Recently in the U2 discussion group, the term "deadly embrace" was used and it became apparent that some people did not understand exactly what it meant.
The Pick database has the ability to lock data records for exclusive access as do most (perhaps all) modern databases. Record locking is a necessary condition in systems with multi-user access, so as to prevent other users from trying to gain write access to a record, while you are updating it.
Sometimes, an update process will only update one type of record at a time, for example a program that maintains a Zip Code table, should only be updating one zip code at a time, perhaps with the name of a city and state.
Often however in an update process, you will end up updating more than one type of record. For example a program that maintains a Customer table, may update not just the Customer table itself, but subsidiary tables, for example a Sales Rep table or a Street Names table or a Property Table. Some programs will be written to know, in advance, which records they may wish to update, however some will not be able to do that. For example, let's say you lock the customer record "ABC Enterprises" for writing, you may know that the Sales Rep is "John Brown" record 1125 in the Sales Rep table. However you may go to that field and change the Sales Rep to "Mary Smith" record 987 in the Sales Rep table. While on that field in the Customer table, you may wish to "pop over" to that Sales Rep table, and also update Mary's phone number.
[Edit]
You have just locked a record for Mary Smith, that the program, when you started could not possibly know that you were going to lock. Meanwhile, you have the Customer record for "ABC Enterprises" still locked as well. At this moment you have locked the Customer record, and then the Sales Rep record in that order, and with perhaps a several minute delay between when those locks were set.
Now let's imagine that programmer B, your evil associate, writes a batch program to increase sales commission for all reps by 5%, however if this makes any rep earn more than 20% commission on the West Coast, then they should be removed from that customer's record entirely and the rep reset there to "House". The batch program kicks off and merrily starts locking and updating records, however, it locks the sales rep record first each time, and only sometimes needs to also lock the customer record.
Joan, your order clerk, goes into a customer to change the sales rep, she locks the customer record first, and only sometimes the sales rep in that order, if she wants to also change something on the sales rep table.
You've now setup the conditions for a deadly embrace to occur. Joan, while in the customer, goes to lock the sales rep, meanwhile the batch program has just co-incidentally hit that same sales rep, and needs to lock this same customer. It already has the sales rep record locked, so Joan has to wait. But Joan has the customer record locked, so the batch program has to wait.
[Edit]
They both wait forever, for the other process to release it's resource, which it will never do, as it's waiting for the other resource that the other process has locked.
That is a deadly embrace. They are each, embracing the other.
A deadly embrace is not just a process waiting for a resource, but rather, it's two (or more) processes, both holding a resource and also waiting on a resouce that someone else is holding, who is waiting on them.
There is no known trivial solution to this computer programming / database problem.
Luckily for Pick programmers, and other database programmers, the situation is rare. Even in companies running hundreds of programs, with dozens of phantoms running, web interfaces, twelve programmers, and two hundred employees in nine countries... it's rare.