When to Defer Constraints until Commit

Constraints that are deferred until commit will be executed in the transaction in which they were triggered. One reason for deferring a constraint until commit could be performance. If a constraint is triggered more than once in the same way in the current transaction, if it is deferred it will be executed only once, during the commit cycle. This can increase performance significantly, especially for large transactions. A disadvantage is that the changes performed by the deferred constraint are not directly visible within the running transaction, so it is not possible to react to them and intervene if required. In general, the final outcome is often the same, but there can be differences.

For example, imagine the following scenario:

·	A constraint exists that deletes all records in table CONTRACT_DETAILS when the STATUS flag in table CONTRACT is set to 'CANCELED'.

·	A user changes the status-flag from 'OPEN' to 'CANCELED' and performs a store record.

·	The user notices that a mistake has been made and changes the status flag to 'CLOSED'.

·	The user then commits the changes.

Now it will depend upon the moment of firing of the constraint whether the details are deleted or not. The developer must decide what is required. Only if commit is considered to be the moment to execute a corrective constraint should the constraint be deferred until commit. It is good practice to make sure that all constraints are defined in such a way that they do not depend upon each other. From the rules point of view it will then not matter whether they are fired upon a save local or upon commit: the result should be the same.

When deferring constraints until commit, it might be desirable to find out what kind of corrections the Rules Engine will perform during the commit cycle before data is actually committed to the database. You can do this by telling the Rules Engine to execute a pre-commit. This will trigger all corrections and check all violations, but it will not perform the final RDBMS commit. In this way you can check that all the corrections made are appropriate, and that there will be no problems when executing the final commit. Such a pre-commit can be issued using the precommit method of the RulesEngine method:

INVOKE RulesEngine.PreCommit.

NOTE:

The precommit method cannot be issued from within a constraint.