Post-transaction Filters

The previous two chapters described two types of user-defined functions called event listeners and transaction filters. Post transaction filters provide a third way to implement your own functions. The differences between the three types can be summarized as follows:

  • An event listener is executed after a specified type of object transaction (create, update or delete) has completed. It is triggered by the event system.

  • A transaction filter is executed during a specified type of object transaction (create, update or delete), before it is completed. Specifically, it is executed immediately before the commit that terminates the transaction, giving it the opportunity to modify the data that is committed. It is not triggered by the event system, but directly called by the Content Engine module that performs the transaction.

  • A post-transaction filter is similar to a transaction filter in the following respects:

    • It is executed during an object transaction.

    • It is not event-dependent, but called directly by the Content Engine module that performs the transaction.

    On the other hand, it is similar to an event listener in that it is executed right at the end of the transaction, after the object has been committed, and can therefore not affect the outcome of the transaction.

These differences mean that a post-transaction filter can be used to carry out the same types of function as an event listener. It is, however, likely to be somewhat more reliable than a post-transaction filter because it does not depend on the timely delivery of an event. It is possible, for example, for some other operation to be executed between the end of a transaction and the execution of a event listener triggered by it, thus affecting the operation of the event listener. On the other hand, an event listener does not need to run on the same host as the Content Engine to which it is responding, making it more flexible. In a multi-host installation, you may want an event listener running on one of your hosts to be able to respond to events triggered by any of the Content Engines in the cluster.