Deferred table constraints
By default, a USoft table constraint is evaluated at the time when data are manipulated, since data manipulation is what triggers the required restrictive or corrective action.
By way of exception, you can defer the action of a table constraint to the time just before or just after the transaction's commit. Do this by setting the Deferred constraint attribute:
Deferring constraints is an advanced feature
Deferring constraints is an advanced feature. As a developer, you should not normally be concerned about constraint deferral. Deferring a constraint does not change the constraint's functional effect, which is to guarantee the aspect of data integrity that it defines. Keep the default Deferred = "Do Not Defer" unless you have special reasons.
A reason to set Deferred = Until Commit is to improve a constraint's performance, since the constraint will no longer be evaluated at each individual record manipulation but only once for the transaction as a whole. To take advantage of this option, you need to be familiar not just with constraint deferral but with all aspects of the constraint activation model, which is the model that describes how a set of interrelated constraints is physically executed at runtime. Constraint activation order does not just depend on the Deferred setting. The constraint activation model is published and explained in the USoft Rules Engine Guide which is part of USoft Definer Help.
A reason to set Deferred = Post Commit is to achieve transaction chaining, an architectural principle in which events in one transaction cause further events in the next transaction. This is particularly interesting when you apply USoft constraints to complex event processing in a service-oriented web application. For details, see the USoft Service Definer Guide.
Which constraints may be deferred?
You can only defer corrective, non-transitional table constraints. This includes INVOKE constraints: for example, you can invoke a constraint executing an XML.IMPORT statement.