When Not to Lock Parent Records

In some specific situations, you might want to disable the locking of parent records at commit time. You can disable locking for one relationship, or for all relationships.

Background

To minimize potential lock conflicts, the Rules Engine performs a minimum amount of locking. For restrictive checks where locking is necessary, the main strategy is that records are locked no sooner than at commit time, and that commit follows as soon as possible after the lock.

As an example, consider manually entered foreign key values (as opposed to values retrieved from a lookup window). At group validation time, just after field validation, these foreign keys are checked for the first time. This is to prevent the user from having to wait until commit.

The parent record is not locked until commit. This lock is also a second check: if the parent record cannot be locked, then the integrity of the entered foreign key value is no longer guaranteed. Between the lock and the actual commit, all restrictive multi-record constraints that need the parent record are evaluated.

In spite of all this, locking in this way may prove unacceptable to your organization. It does mean that two users cannot concurrently add a new child to the same parent.

When to use

There may be reasons why this check is unnecessary. For instance, the parent table is protected against any data manipulation other than INSERT, or a parent table contains relatively few records with many children. In this case, users changing or inserting unrelated child records could lock each other out. When the parent tables are not subject to many changes it may be better not to lock the parent. In such cases, you may decide the lock is unnecessary and:

•Clear the Lock Foreign Key on Check attribute for one relationship,

or

•Set the Lock Foreign Keys deployment configuration setting in the Authorizer (default is Yes) for the entire application.

To prevent locks on parent records for the entire application:

Limitations

Only set the Lock Foreign Keys property to No if you are absolutely sure this will not harm the integrity of the data. This property does not apply to Sybase.