Under no circumstances do you want to hold a record lock longer than you need it. The best way to make sure you get the locking you want is to be explicit about it. Do not fall back on ABL defaults, which try to give you reasonable behavior when you do not specify the behavior you want, but which cannot always anticipate what your procedure really requires. Here are two guidelines for using locks:

  • Never read a record before a transaction starts, even with NO-LOCK , if you are going to update it inside the transaction. If you read a record with NO-LOCK before a transaction starts and then read the same record with EXCLUSIVE-LOCK within the transaction, the lock is automatically downgraded to a SHARE-LOCK when the transaction ends. The AVM does not automatically return you to NO-LOCK status.
  • If you have any doubt at all about when a record goes out of scope or when a lock is released, release the record explicitly when you are done updating it with the RELEASE statement. If you release the record, you know that it is no longer locked, and that you cannot unwittingly have a reference to it after the transaction block that would extend the scope of the lock, or even the transaction.

If you observe these two simple guidelines, your programming is greatly simplified and much more reliable. Here are a few rules that you simply do not need to worry about if you acquire records only within a transaction and always release them when you are done:

  • A SHARE-LOCK is held until the end of the transaction or the record release, whichever is later. If you avoid SHARE-LOCKs and always release records when you're done updating them, the scary phrase whichever is later does not apply to your procedure.
  • An EXCLUSIVE-LOCK is held until transaction end and then converted to a SHARE-LOCK if the record scope is larger than the transaction and the record is still active in any buffer. Again, releasing the record assures you that the use of the record in the transaction does not conflict with a separate use of the same record outside the transaction.
  • When the AVM backs out a transaction, it releases locks acquired within a transaction or changes them to SHARE-LOCK if it locked the records prior to the transaction. If you do not acquire locks or even records outside a transaction, you do not need to worry about this special case.

Lock table resources

SHARE-LOCKs and EXCLUSIVE-LOCKs use up entries in a lock table maintained by the database manager. The possible number of entries in the lock table defaults to 500. You can change this number using the Lock Table Entries (-L) startup parameter for your OpenEdge session. The AVM stops a program if it attempts to access a record that causes it to overflow the lock table.