TechTip: Preventing Record Lock, Part 1
** This thread discusses the article: TechTip: Preventing Record Lock, Part 1 **
I'd like to throw in my 2 cent's worth. To me, most of this is focusing on the wrong part of the problem. Interactive programs have the brains of the client behind them (that is, backing up the logic of the program of course). Issue the lock message to that client in whatever format makes sense to you, the client, and however your programming practices dictate. It's the batch programs that are having the biggest problem, so fix them! I routinely code batch programs to deal with record locks. These programs all have auditable reports anyways, so simply kick out the transactions that have problems with a suitable error message. You don't stop the program unless continuing would cause other major issues. As a last resort, we can run batch updates during our time-critical section of nightly processing, which kicks everyone off the system anyways. Note that this is truly a last resort, however, because downtime is a Bad Thing. The system has been carefully created to minimize downtime and we need to support that. This technique gets 99.99% of the work done, when it needs to be done. Problems are dealt with on an exception basis, which makes business sense (and not just technological sense).
** This thread discusses the article: TechTip: Preventing Record Lock, Part 1 **
I'd like to throw in my 2 cent's worth. To me, most of this is focusing on the wrong part of the problem. Interactive programs have the brains of the client behind them (that is, backing up the logic of the program of course). Issue the lock message to that client in whatever format makes sense to you, the client, and however your programming practices dictate. It's the batch programs that are having the biggest problem, so fix them! I routinely code batch programs to deal with record locks. These programs all have auditable reports anyways, so simply kick out the transactions that have problems with a suitable error message. You don't stop the program unless continuing would cause other major issues. As a last resort, we can run batch updates during our time-critical section of nightly processing, which kicks everyone off the system anyways. Note that this is truly a last resort, however, because downtime is a Bad Thing. The system has been carefully created to minimize downtime and we need to support that. This technique gets 99.99% of the work done, when it needs to be done. Problems are dealt with on an exception basis, which makes business sense (and not just technological sense).
Comment