Library Version 12.1.6.0

Event Handling
Prev | Chapter 1. Introduction | Next

## Event Handling

The replication system is capable of reporting a great many events to which your code might need to respond. To track and respond to these events, you implement a callback whose function it is to respond to events that happen within the DB library.

Note that this callback is usable for events beyond those required for replication purposes. In this section, however, we only discuss some of the replication-specific events.

The callback is required to determine which event has been passed to it, and then take action depending on the event.

Some of the more commonly handled replication events are described below. For a complete list of events, see the `DbEnv::set_event_notify()` method in the Berkeley DB C++ API Reference Guide.

- `DB_EVENT_REP_CLIENT`

  The local environment is now a replica.

- `DB_EVENT_REP_LOCAL_SITE_REMOVED`

  The local Replication Manager site has been removed from the group.

- `DB_EVENT_REP_MASTER`

  The local environment is now a master.

- `DB_EVENT_REP_NEWMASTER`

  An election was held and a new environment was made a master. However, the current environment is not the master. This event exists so that you can cause your code to take some unique action in the event that the replication groups switches masters.

- `DB_EVENT_REP_PERM_FAILED`

  The Replication Manager did not receive enough acknowledgements to ensure the transaction's durability within the replicationg group. The Replication Manager has therefore flushed the transaction to the master's local disk for storage.

  How the Replication Manager knows whether the acknowledgements it has received is determined by the acknowledgement policy you have set for your applicaton. See Identifying Permanent Message Policies for more information.

- `DB_EVENT_REP_SITE_ADDED`

  A new Replication Manager site has joined the replication group.

- `DB_EVENT_REP_SITE_REMOVED`

  An existing Replication Manager site has been removed from the replication group.

- `DB_EVENT_REP_STARTUPDONE`

  The replica has completed startup synchronization and is now processing log records received from the master.

For an example of how to use this callback, see Determining State

Prev | Up | Next
Permanent Message Handling | Home | Chapter 2. Transactional Application