Lock and Commit Management

To minimize potential lock conflicts, the Rules Engine tries to have records locked for a minimum of time. 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. The situations in which the Rules Engine locks records are:

·	Because of user manipulation:

When the user deletes a record or changes a field value in a record, the record is immediately locked.

·	At record validation time:

When cascading or nullifying update or delete rules take place, the child records are locked just after the parent record has been updated or deleted.

When corrective multi-record constraints apply, before the constraint manipulates a record, this record will be locked.

·	At commit time:

Just before the final foreign key checks and relationship cardinality checks are executed, the parent records are locked. If the record cannot be locked, then the integrity of the foreign key value is no longer guaranteed.

Just before the final constraint tests take place for restrictive multi-record constraints, the driving table records of these constraints are locked. For details, see "Driving Tables".