Recapture replicated transactions

If you want a transaction to continue to be replicated after it reaches the target replication servers, you can use the ifx_set_erstate() procedure.

By default, when Enterprise Replication reads the logical logs to capture transactions, replicated transactions are ignored. For example, if a transaction is replicated from serv1 to serv2, that transaction is not captured for replication on serv2 because it has already been replicated. Replication stops when transactions reach target servers, but you can configure a transaction to be recaptured and continue to be replicated. You must reset the replication state back to the default at the end of the transaction or replication loops indefinitely.

Example

Suppose that a retail chain wants to run a procedure to create a report that populates a summary table of each store's current inventory and then replicates that summary information to a central server. A stored procedure named low_inventory() that creates a low inventory report exists on all replications servers. The following example creates a new procedure named xqt_low_inventory() that enables replication for the low_inventory() procedure, and then runs the low_inventory() procedure:

CREATE PROCEDURE xqt_low_inventory()
	DEFINE curstate integer;
	EXECUTE FUNCTION ifx_get_erstate() INTO curstate;
	EXECUTE PROCEDURE ifx_set_erstate(1);
	EXECUTE PROCEDURE low_inventory();
	EXECUTE PROCEDURE ifx_set_erstate(curstate);
END PROCEDURE;

The following events occur in this procedure:

  1. The xqt_low_inventory() procedure defines a data variable called curstate to hold the Enterprise Replication state information.
  2. The ifx_get_erstate() function obtains the Enterprise Replication state and stores it in the curstate variable. The ifx_set_state() procedure enables replication.
  3. The low_inventory() procedure is run.
  4. The replication state is reset back to its original value.

When a transaction runs the xqt_low_inventory() procedure, the execution of the procedure is replicated to all replication servers and the result of the low_inventory() procedure is then replicated like any normal updating activity.