Using a Return Service

RETURN RECEIPT

TimesTen Classic provides an optional return receipt service to loosely couple or synchronize your application with the replication mechanism.

In an active standby pair, you can specify the RETURN RECEIPT clause to enable the return receipt service for the standby database. With return receipt enabled, when your application commits a transaction for an element on the active database, the application remains blocked until the standby acknowledges receipt of the transaction update.
In a classic replication scheme, you can specify the RETURN RECEIPT clause to enable the return receipt service for the subscriber database. With return receipt enabled, when your application commits a transaction for an element on the master database, the application remains blocked until the subscriber acknowledges receipt of the transaction update. If the master is replicating the element to multiple subscribers, the application remains blocked until all of the subscribers have acknowledged receipt of the transaction update.

Note:

You can also configure the replication agent to disable the return receipt service after a specific number of timeouts. See Setting the Return Service Timeout Period.

If the standby or subscriber is unable to acknowledge receipt of the transaction within a configurable timeout period, your application receives a tt_ErrRepReturnFailed (8170) warning on its commit request.

The following example defines return receipt for an active standby pair. This example creates an active standby pair where master1 is the active database, master2 is the standby database. The standby database is enabled with the return receipt service.

Command> CREATE ACTIVE STANDBY PAIR 
  master1, 
  master2 
  RETURN RECEIPT;

The following example defines return receipt for a classic replication scheme. To confirm that all transactions committed on the tab table in the master database (masterds) are received by the subscriber (subscriberds), the element description (e) might look like the following:

Note:

For more examples of classic replication schemes that use return receipt services, see Multiple Subscriber Classic Replication Schemes.

ELEMENT e TABLE tab
    MASTER masterds ON "system1"
    SUBSCRIBER subscriberds ON "system2"
      RETURN RECEIPT

RETURN RECEIPT BY REQUEST

RETURN RECEIPT enables notification of receipt for all transactions.

You can use the RETURN RECEIPT BY REQUEST clause to enable an acknowledgement receipt notification only for specific transactions identified by your application.

If you specify RETURN RECEIPT BY REQUEST, you must use the ttRepSyncSet built-in procedure on the active or master database to enable the return receipt service for a transaction. The call to enable the return receipt service must be part of the transaction (autocommit must be off).

If the standby or subscriber database is unable to acknowledge receipt of the transaction update within a configurable timeout period, the application receives a tt_ErrRepReturnFailed (8170) warning on its commit request. See Setting the Return Service Timeout Period.

The following example defines return receipt by request for an active standby pair. This example creates an active standby pair where master1 is the active database and master2 is the standby database. The standby database is enabled with the return receipt service.

Command> CREATE ACTIVE STANDBY PAIR 
  master1, 
  master2 
  RETURN RECEIPT BY REQUEST;

This example defines return receipt by request for a classic replication scheme. To enable confirmation that specific transactions committed on the tab table in the master database (masterds) are received by the subscriber (subscriberds), the element description (e) might look like:

ELEMENT e TABLE tab
    MASTER masterds ON "system1"
    SUBSCRIBER subscriberds ON "system2"
      RETURN RECEIPT BY REQUEST

You can use ttRepSyncSet to request return services. Before committing a transaction that requires an acknowledgement return receipt, call ttRepSyncSet. The following example sets the request for a return receipt with the first column set to 0x01 with a timeout value of 45 seconds in column two.

Command> autocommit off;
Command> CALL ttRepSyncSet(0x01, 45, 1);

You can use ttRepSyncGet to check if a return service is enabled and obtain the timeout value. The following demonstrates that the values that were previously set with the ttRepSyncSet built-in procedure.

Command> CALL ttRepSyncGet;
< 01, 45, 1 >
1 row found.

See ttRepSyncSet and ttRepSyncGet in the Oracle TimesTen In-Memory Database Reference.

RETURN TWOSAFE

TimesTen Classic provides a return twosafe service to fully synchronize your application with the replication mechanism.

The return twosafe service ensures that each replicated transaction is committed on the standby database before it is committed on the active database. If replication is unable to verify the transaction has been committed on the standby or subscriber, it returns notification of the error. Upon receiving an error, the application can either take a unique action or fall back on preconfigured actions, depending on the type of failure.

Note:

When replication is configured with RETURN TWOSAFE, you must disable autocommit mode.

To enable the return twosafe service for the subscriber, specify the RETURN TWOSAFE attribute in the CREATE ACTIVE STANDBY PAIR, ALTER ACTIVE STANDBY PAIR, CREATE REPLICATION, or ALTER REPLICATION statements.

When using an active standby pair, a transaction that contains operations that are replicated with RETURN TWOSAFE cannot have a PassThrough setting greater than 0. If PassThrough is greater than 0, an error is returned and the transaction must be rolled back.
When using a classic replication scheme, the return twosafe service is intended to be used in replication schemes where two databases must stay synchronized. One database has an active role, while the other database has a standby role but must be ready to assume an active role at any moment. Use return twosafe with a bidirectional replication scheme with exactly two databases.

When the application commits a transaction on the master database, the application remains blocked until the subscriber acknowledges it has successfully committed the transaction. Initiating identical updates or deletes on both databases can lead to deadlocks in commits that can be resolved only by stopping the processes.

If the standby or subscriber is unable to acknowledge commit of the transaction update within a configurable timeout period, the application receives a tt_ErrRepReturnFailed (8170) warning on its commit request. See Setting the Return Service Timeout Period.

The following example defines return twosafe service for an active standby pair. This example creates an active standby pair where master1 is the active database, master2 is the standby database. The standby database is enabled with the return twosafe service.

Command> CREATE ACTIVE STANDBY PAIR 
  master1, 
  master2 
  RETURN TWOSAFE;

The following example defines return twosafe service for a classic replication scheme. To confirm all transactions committed on the master database (databaseA) are also committed by the subscriber (databaseB), the element description (a) might look like the following:

ELEMENT a DATASTORE
    MASTER databaseA ON "system1"
    SUBSCRIBER databaseB ON "system2"
      RETURN TWOSAFE

The entire CREATE REPLICATION statement that specifies both databaseA and databaseB in a bidirectional configuration with RETURN TWOSAFE might look like the following:

CREATE REPLICATION bidirect
ELEMENT a DATASTORE
    MASTER databaseA ON "system1"
    SUBSCRIBER databaseB ON "system2"
      RETURN TWOSAFE
ELEMENT b DATASTORE
    MASTER databaseB ON "system2"
    SUBSCRIBER databaseA ON "system1"
      RETURN TWOSAFE;

RETURN TWOSAFE BY REQUEST

RETURN TWOSAFE enables notification of commit on the standby database for all transactions.

You can use the RETURN TWOSAFE BY REQUEST clause to enable notification of a commit on the standby only for specific transactions identified by your application.

If you specify RETURN TWOSAFE BY REQUEST for a standby or subscriber database, you must use the ttRepSyncSet built-in procedure on the active or master database to enable the return twosafe service for a transaction. The call to enable the return twosafe service must be part of the transaction (autocommit must be off).

When you use the ALTER TABLE statement to alter a replicated table that is part of a RETURN TWOSAFE BY REQUEST transaction, it ends up not running as a part of the TWOSAFE BY REQUEST transaction. Instead, the ALTER TABLE operation succeeds because a commit is performed before the ALTER TABLE operation, resulting in the ALTER TABLE operation running in a new transaction which is not part of the RETURN TWOSAFE BY REQUEST transaction.

Note:

See Setting the Return Service Timeout Period.

If the standby or subscriber is unable to acknowledge commit of the transaction within the timeout period, the application receives a tt_ErrRepReturnFailed (8170) warning on its commit request. The application can then chose how to handle the timeout. See Setting the Return Service Timeout Period.

When using an active standby pair, a transaction that contains operations that are replicated with RETURN TWOSAFE cannot have a PassThrough setting greater than 0. If PassThrough is greater than 0, an error is returned and the transaction must be rolled back.

The following example defines return twosafe by request service for an active standby pair. This example creates an active standby pair where master1 is the active database, master2 is the standby database. The standby database is enabled with the return twosafe by request service.

Command> CREATE ACTIVE STANDBY PAIR 
  master1, 
  master2 
  RETURN TWOSAFE BY REQUEST;

Before calling commit for a transaction that requires confirmation of commit on the subscriber, call the ttRepSyncSet built-in procedure to request the return service, set the timeout period to 45 seconds, and specify no action (1) in the event of a timeout error:

Command> CALL ttRepSyncSet(0x01, 45, 1);

You can use the ttRepSyncGet built-in procedure to check if a return service is enabled and obtain the timeout value.

Command> CALL ttRepSyncGet();
< 01, 45, 1>
1 row found.

This example defines return twosafe by request for a classic replication scheme. To enable confirmation that specific transactions committed on the master database (databaseA) are also committed by the subscriber (databaseB), the element description (a) might look like:

ELEMENT a DATASTORE
    MASTER databaseA ON "system1"
    SUBSCRIBER databaseB ON "system2"
      RETURN TWOSAFE BY REQUEST;

Before calling commit for a transaction that requires confirmation of commit on the subscriber, call the ttRepSyncSet built-in procedure to request the return service, set the timeout period to 45 seconds, and specify no action (1) in the event of a timeout error:

Command> CALL ttRepSyncSet(0x01, 45, 1);

You can use the ttRepSyncGet built-in procedure to check if a return service is enabled and obtain the timeout value.

Command> CALL ttRepSyncGet();
< 01, 45, 1>
1 row found.

NO RETURN

You can use the NO RETURN clause to explicitly disable either the return receipt or return twosafe services, depending on which one you have enabled.

NO RETURN is the default condition. This attribute is typically used only when altering a replication scheme to remove a previously defined return service in the ALTER ACTIVE STANDBY PAIR or ALTER REPLICATION statements.

Specifying a Different Return Service for Each Subscriber in a Classic Replication Scheme

In a classic replication scheme, you can specify a different return service for table elements and database elements for the subscribers listed in each SUBSCRIBER clause in a CREATE REPLICATION or ALTER REPLICATION statement.

The following example shows separate SUBSCRIBER clauses that can define different return service attributes for each subscriber: SubDatabase1 and SubDatabase2.

CREATE REPLICATION Owner.SchemeName
  ELEMENT ElementNameElementType
    MASTER DatabaseName ON "HostName"
    SUBSCRIBER SubDatabase1 ON "HostName" ReturnServiceAttribute1
    SUBSCRIBER SubDatabase2 ON "HostName" ReturnServiceAttribute2;

Alternatively, you can specify the same return service attribute for all of the subscribers defined in an element. The following example shows the use of a single SUBSCRIBER clause that defines the same return service attributes for both SubDatabase1 and SubDatabase2.

CREATE REPLICATION Owner.SchemeName
  ELEMENT ElementNameElementType
    MASTER DatabaseName ON "HostName"
    SUBSCRIBER SubDatabase1 ON "HostName",
               SubDatabase2 ON "HostName"
               ReturnServiceAttribute;

Setting the Return Service Timeout Period

A timeout can occur in a replication scheme configured with one of the return services.

See Using a Return Service.

In an active standby pair replication scheme, a timeout occurs if the standby database is unable to send an acknowledgement back to the active database within the time period specified by RETURN WAIT TIME.

If the standby database is unable to acknowledge the transaction update from the active database within the timeout period, the application receives an errRepReturnFailed warning on its commit request.
In a classic replication scheme, a timeout occurs if any of the subscribers are unable to send an acknowledgement back to the master within the time period specified by RETURN WAIT TIME.

The replication state could be set to stop by a user or by the master replication agent in the event of a subscriber failure. A subscriber may be unable to acknowledge a transaction that makes use of a return service and may time out with respect to the master.

If any of the subscribers are unable to acknowledge the transaction update within the timeout period, the application receives an errRepReturnFailed warning on its commit request.

A return service may time out because of a replication failure or because replication is so far behind that the return service transaction times out before it is replicated. However, unless there is a simultaneous replication failure, failure to obtain a return service confirmation from the standby or subscriber does not necessarily mean the transaction has not been or will not be replicated.

The default return service timeout period is 10 seconds. You can specify a different return service timeout period by either:

Specifying the RETURN WAIT TIME in the CREATE ACTIVE STANDBY PAIR, ALTER ACTIVE STANDBY PAIR, CREATE REPLICATION, or ALTER REPLICATION statements.

The RETURN WAIT TIME attribute specifies the number of seconds to wait for a return service acknowledgement. A value of 0 means that there is no waiting.

The following example alters an active database (master1) of an active standby pair to set a return service wait time of 25 seconds:
```
Command> ALTER ACTIVE STANDBY PAIR
  ALTER STORE master1 SET RETURN WAIT TIME 25;
```
Specifying a different return service timeout period programmatically by calling the ttRepSyncSet built-in procedure on either the active database (in an active standby pair) or the master database (in a classic replication scheme) with a new timeout value for the returnWait parameter.

The following example demonstrates how to set the return service wait time to 25 seconds using ttRepSyncSet:
```
Command> CALL ttRepSyncSet (0x01, 25, 1);
```

Once the timeout is set, the timeout period applies to all subsequent return service transactions until you either reset the timeout period or terminate the application session. For a classic replication scheme, the timeout setting applies to all return services for all subscribers.

Note:

You can set other STORE attributes to establish policies that automatically disable return service blocking in the event of excessive timeouts and re-enable return service blocking when conditions improve. See Establishing Return Service Failure and Recovery Policies.

This example sets the timeout period for both databases included in a bidirectional classic replication scheme. To set the timeout period to 30 seconds for both bidirectionally replicated databases, databaseA and databaseB, in the bidirect replication scheme, the CREATE REPLICATION statement might look like the following:

CREATE REPLICATION bidirect
ELEMENT a DATASTORE
    MASTER databaseA ON "system1"
    SUBSCRIBER databaseB ON "system2"
      RETURN TWOSAFE
ELEMENT b DATASTORE
    MASTER databaseB ON "system2"
    SUBSCRIBER databaseA ON "system1"
      RETURN TWOSAFE
STORE databaseA RETURN WAIT TIME 30
STORE databaseB RETURN WAIT TIME 30;

This example shows how to reset the timeout period. Use the ttRepSyncSet built-in procedure to reset the timeout period to 45 seconds. To avoid resetting the requestReturn and localAction values, specify NULL:

Command> CALL ttRepSyncSet(NULL, 45, NULL);

Disabling Return Service Blocking Manually

You may want to react if replication is stopped or return service timeout failures begin to adversely impact the performance of your replicated system.

Your "tolerance threshold" for return service timeouts may depend on the historical frequency of timeouts and the performance/availability equation for your particular application, both of which should be factored into your response to the problem.

Note:

One response to a timeout is to disable the return service. You can determine if the return service is enabled or disabled with either the ttRepSyncSubscriberStatus built-in procedure. See Determine If Return Service Is Disabled.

When using the return receipt service, you can manually respond by:

Using the ALTER ACTIVE STANDBY PAIR or ALTER REPLICATION statements to disable return receipt blocking. If you decide to disable return receipt blocking, your decision to re-enable it depends on your confidence level that the return receipt transaction is no longer likely to time out.

The following example uses the ALTER ACTIVE STANDBY PAIR statement to disable return receipt after 10 failures:
```
Command> ALTER ACTIVE STANDBY PAIR
  ALTER STORE master1 SET DISABLE RETURN ALL 10;
```
Calling the ttDurableCommit built-in procedure to durably commit transactions on the active or master database that you can no longer verify as being received by the standby or subscriber database.

Establishing Return Service Failure and Recovery Policies

An alternative to manually responding to return service timeout failures is to establish return service failure and recovery policies in the replication scheme.

These policies direct the replication agents to detect changes to the replication state and to keep track of return service timeouts and then automatically respond in a predefined manner.

The following attributes in the CREATE ACTIVE STANDBY PAIR, ALTER ACTIVE STANDBY PAIR, CREATE REPLICATION, or ALTER REPLICATION statements set the failure and recovery policies when using a RETURN RECEIPT or RETURN TWOSAFE service:

The policies set by these attributes are applicable until changed. Except for DURABLE COMMIT, the replication agent must be running to enforce these policies.

RETURN SERVICES {ON | OFF} WHEN [REPLICATION] STOPPED

The RETURN SERVICES {ON | OFF} WHEN [REPLICATION] STOPPED attribute determines whether a return receipt or return two safe service continues to be enabled or is disabled when replication is paused or stopped.

For an active standby pair, replication is considered stopped when either:
- The active replication agent has failed or is explicitly stopped (for example, by ttAdmin -repStop active).
- A failed standby master that has exceeded the specified FAILTHRESHOLD value stops replication. Note that even though replication is stopped when the standby master fails, TimesTen replicates directly from the active master to any subscribers, bypassing the standby master. All missing updates are propagated to the standby master if it recovers.
In a classic replication scheme, replication is considered stopped when either:
- The master replication agent is explicitly stopped (for example, by ttAdmin -repStop master).
- The replication state of the subscriber database is set to pause or stop (for example, by ttRepAdmin -state pause subscriber).
- A failed subscriber that has exceeded the specified FAILTHRESHOLD value stops replication.

Note:

A standby or subscriber database may become unavailable for a period of time that exceeds the timeout period specified by RETURN WAIT TIME, yet may still be considered by the master replication agent to be in the start state. Failure policies related to timeouts are set by the DISABLE RETURN attribute.

You can enable or disable the return service when replication is stopped with the following clause:

RETURN SERVICES OFF WHEN REPLICATION STOPPED disables the return service when replication is stopped and is the default when using the RETURN RECEIPT service.
RETURN SERVICES ON WHEN REPLICATION STOPPED enables the return service to continue to be enabled when replication is stopped and is the default when using the RETURN TWOSAFE service.

The following example defines return services on when replication stopped for an active standby pair. This example creates an active standby pair with RETURN TWOSAFE return service and defines that the return service is to be disabled when replication is stopped (which is opposite of the default).

Command> CREATE ACTIVE STANDBY PAIR 
  master1, 
  master2 
  RETURN TWOSAFE 
  STORE master2 RETURN SERVICES OFF WHEN REPLICATION STOPPED;

This example defines return services on when replication stopped for a classic replication scheme.

Configure the CREATE REPLICATION statement to replicate updates from the masterds database to the subscriber1 database. The CREATE REPLICATION statement specifies the use of RETURN RECEIPT and RETURN SERVICES ON WHEN REPLICATION STOPPED.

CREATE REPLICATION myscheme
 ELEMENT e TABLE tab
  MASTER masterds ON "server1"
  SUBSCRIBER subscriber1 ON "server2"
  RETURN RECEIPT
  STORE masterds ON "server1"
    RETURN SERVICES ON WHEN REPLICATION STOPPED;

While the application is committing updates to the master, you could use the ttRepAdmin -state pause to set subscriber1 to the pause state:

ttRepAdmin -receiver -name subscriber1 -state pause masterds

At this point, the application would continue to wait for return receipt acknowledgements from subscriber1 until the replication state is reset to start and it receives the acknowledgment:

ttRepAdmin -receiver -name subscriber1 -state start masterds

Note:

See Set the Replication State of Subscribers. You should be cautious about setting the subscriber state to stop, as this not only stops the replication to this subscriber, but also discards all of the updates. If you did set the subscriber to the stop state, you would need to perform a duplicate to restore the subscriber.

DISABLE RETURN

When a DISABLE RETURN value is set, the database keeps track of the number of return receipt or return twosafe transactions that have exceeded the timeout period set by RETURN WAIT TIME.

If the number of timeouts exceeds the maximum value set by DISABLE RETURN, the application reverts to a default replication cycle in which it no longer waits for the standby or subscriber to acknowledge the replicated updates.

When return service blocking is disabled, the applications on the active or master database no longer blocks processing while waiting to receive acknowledgements from the standby or subscribers that they received or committed the replicated updates. Transactions are still replicated to the standby or subscriber, whether the return service is enabled or disabled. When the return service is disabled, the transactions are sent in asynchronous mode; the active or master database continues to listen for an acknowledgement of each batch of replicated updates from standby or subscriber databases.

Configure DISABLE RETURN as follows:

For an active standby pair, specifying SUBSCRIBER is the same as specifying ALL. Both settings refer to the standby database.
For a classic replication scheme, you can set DISABLE RETURN SUBSCRIBER to establish a failure policy to disable return service blocking for only those subscribers that have timed out, or DISABLE RETURN ALL to establish a policy to disable return service blocking for all subscribers.

Note:

You can use the ttRepSyncSubscriberStatus built-in procedure to determine whether the standby database or a particular subscriber has been disabled by the DISABLE RETURN failure policy.

The DISABLE RETURN failure policy is only enabled when the replication agent is running. If DISABLE RETURN is specified without RESUME RETURN, the return services remain off until the replication agent for the database has been restarted.

For an active standby pair, you can cancel this failure policy by stopping the replication agent and specifying DISABLE RETURN with a zero value for NumFailures.
For a classic replication scheme, you can cancel this failure policy by stopping the replication agent and specifying either DISABLE RETURN SUBSCRIBER or DISABLE RETURN ALL with a zero value for NumFailures.

DISABLE RETURN maintains a cumulative timeout count for each subscriber. If there are multiple subscribers and you set DISABLE RETURN SUBSCRIBER, the replication agent disables return service blocking for the first subscriber that reaches the timeout threshold. If one of the other subscribers later reaches the timeout threshold, the replication agent disables return service blocking for that subscriber also.

The count of timeouts to trigger the failure policy is reset either when you restart the replication agent, when you set the DISABLE RETURN value to 0, or when return service blocking is re-enabled by RESUME RETURN.

This example shows how to set DISABLE RETURN for an active standby pair. Configure the CREATE ACTIVE STANDBY PAIR statement to replicate updates from the active database master1 to the standby database master2. The CREATE ACTIVE STANDBY PAIR statement specifies the use of RETURN RECEIPT and DISABLE RETURN ALL with a NumFailures value of 5. The RETURN WAIT TIME is set to 30 seconds.

CREATE ACTIVE STANDBY PAIR 
   master1, 
   master2 
   RETURN RECEIPT 
   STORE master1 
   DISABLE RETURN ALL 5
   RETURN WAIT TIME 30;

While the application is committing updates to the active database, the standby database (master2) experiences problems and fails to acknowledge a replicated transaction update. The application is blocked for 30 seconds after which it commits its next update to the active database master1. Over the course of the application session, this commit/timeout cycle repeats 4 more times until DISABLE RETURN disables return receipt blocking for master2.

The following example sets the DISABLE RETURN SUBSCRIBER for a classic replication scheme. Configure the CREATE REPLICATION statement to replicate updates from the masterds master database to the subscriber databases: subscriber1 and subscriber2. The CREATE REPLICATION statement specifies the use of RETURN RECEIPT and DISABLE RETURN SUBSCRIBER with a NumFailures value of 5. The RETURN WAIT TIME is set to 30 seconds.

CREATE REPLICATION myscheme
 ELEMENT e TABLE tab
   MASTER masterds ON "server1"
   SUBSCRIBER subscriber1 ON "server2",
             subscriber2 ON "server3"
 RETURN RECEIPT
 STORE masterds ON "server1"
   DISABLE RETURN SUBSCRIBER 5
   RETURN WAIT TIME 30;

While the application is committing updates to the master, subscriber1 experiences problems and fails to acknowledge a replicated transaction update. The application is blocked for 30 seconds after which it commits its next update to the master database masterds. Over the course of the application session, this commit/timeout cycle repeats 4 more times until DISABLE RETURN disables return receipt blocking for subscriber1. The application continues to wait for return-receipt acknowledgements from subscriber2, but not from subscriber1.

RESUME RETURN

If DISABLE RETURN has disabled return service blocking, the RESUME RETURN attribute sets the policy for re-enabling the return service. You can establish a return service recovery policy by setting the RESUME RETURN attribute and specifying a resume latency value.

If return service blocking has been disabled for the standby or subscriber database and a latency time has been defined for RESUME RETURN, the following occurs:

The applications on the active or master database no longer block processing while waiting to receive acknowledgements from the standby or subscribers. Transactions continue to be replicated to the standby or subscriber in asynchronous mode. The active or master databases continue to listen for an acknowledgement of each batch of replicated updates from standby or subscriber databases.
If the return service blocking is disabled, RESUME RETURN evaluates the commit-to-acknowledge time for the last transaction to see if the latency is less than the latency limit configured by the RESUME RETURN. If the commit-to-acknowledge time latency is less than the latency limit set by RESUME RETURN, TimesTen re-enables the return receipt or return twosafe services.

Note:

The commit-to-acknowledge time latency is the time elapsed between when the application issues a commit and when the active or master database receives acknowledgement from the standby or subscriber.

TimesTen evaluates the latency of the last acknowledged transaction before the current transaction is replicated to the standby or subscriber. The return service is re-enabled before the sending of the current transaction after evaluating the latency from the last transaction.

The RESUME RETURN policy is enabled only when the replication agent is running. You can cancel a return receipt resume policy by stopping the replication agent and then using ALTER ACTIVE STANDBY PAIR or ALTER REPLICATION statements to set RESUME RETURN to zero.

The following example sets RESUME RETURN for an active standby pair. If return receipt blocking has been disabled for master2 and if RESUME RETURN is set to 8 milliseconds, then return receipt blocking is re-enabled for master2 the instant the active receives an acknowledgement of the update from the standby, as long as the acknowledgement is received within the specified latency 8 milliseconds from when it was committed by the application on the active database.

Command> CREATE ACTIVE STANDBY PAIR 
  master1, 
  master2 
  RETURN RECEIPT
  STORE master1
  DISABLE RETURN ALL 5
  RESUME RETURN 8;

The following example sets RESUME RETURN for a classic replication scheme. If return receipt blocking has been disabled for subscriber1 and if RESUME RETURN is set to 8 milliseconds, then return receipt blocking is re-enabled for subscriber1 the instant the master receives an acknowledgement of the update from the subscriber, as long as the acknowledgement is received within the specified latency 8 milliseconds from when it was committed by the application on the master database.

CREATE REPLICATION myscheme
 ELEMENT e TABLE ttuser.tab
   MASTER masterds ON "server1"
   SUBSCRIBER subscriber1 ON "server2",
             subscriber2 ON "server3"
 RETURN RECEIPT
 STORE masterds ON "server1"
   DISABLE RETURN SUBSCRIBER 5
   RESUME RETURN 8;

DURABLE COMMIT

When DURABLE COMMIT is set to ON, it overrides the DurableCommits general connection attribute on the active or master database and forces durable commits for those transactions that have had return service blocking disabled.

In addition, when DURABLE COMMIT is set to ON, durable commits are issued when return service blocking is disabled regardless of whether the replication agent is running or stopped. They are also issued when the ttRepStateSave built-in procedure has marked the standby or subscriber database as failed.

For a classic replication scheme, DURABLE COMMIT is useful if you have only one subscriber. However, if you are replicating the same data to two subscribers and you disable return service blocking to one subscriber, then you achieve better performance if you rely on the other subscriber than you would if you enable durable commits.

Set DURABLE COMMIT ON for an active standby pair when establishing a DISABLE RETURN ALL policy to disable return-receipt blocking for all subscribers. If return-receipt blocking is disabled, commits are durably committed to the file system to provide redundancy.

Command> CREATE ACTIVE STANDBY PAIR 
  master1, 
  master2 
  RETURN RECEIPT
  STORE master1
  DISABLE RETURN ALL 5
  DURABLE COMMIT ON
  RESUME RETURN 8;

Set DURABLE COMMIT ON within a classic replication scheme when establishing a DISABLE RETURN ALL policy to disable return-receipt blocking for all subscribers. If return-receipt blocking is disabled, commits are durably committed to the file system to provide redundancy.

CREATE REPLICATION myscheme
 ELEMENT e TABLE tab
   MASTER masterds ON "server1"
   SUBSCRIBER subscriber ON "server2",
             subscriber2 ON "server3"
 RETURN RECEIPT
STORE masterds ON "server1"
   DISABLE RETURN ALL 5
   DURABLE COMMIT ON
   RESUME RETURN 8;

LOCAL COMMIT ACTION

When you are using the return twosafe service, you can specify how the active or master replication agent responds to timeouts by setting LOCAL COMMIT ACTION. You can override this setting for specific transactions with the localAction parameter of the ttRepSyncSet built-in procedure.

The possible actions upon receiving a timeout during replication of a twosafe transaction are:

COMMIT - On timeout, the commit function attempts to perform a commit to end the transaction locally. No more operations are possible on the same transaction.
NO ACTION - On timeout, the commit function returns to the application, leaving the transaction in the same state it was in when it entered the commit call, with the exception that the application is not able to update any replicated tables. The application can reissue the commit. This is the default.

If the call returns with an error, you can use the ttRepXactStatus procedure described in Check the Status of Return Service Transactions to check the status of the transaction. Depending on the error, your application can choose to:

Reissue the commit call - This repeats the entire return twosafe replication cycle, so that the commit call returns when the success or failure of the replicated commit on the subscriber is known or if the timeout period expires.
Roll back the transaction - If the call returns with an error related to applying the transaction on the standby or subscriber, such as primary key lookup failure, you can roll back the transaction on the active or master database.