It is now guaranteed the DB_EVENT_REP_STARTUPDONE event will be presented to the application after the corresponding DB_EVENT_REP_NEWMASTER event, even in the face of extreme thread-scheduling anomalies. (In previous releases, if the thread processing the NEWMASTER message was starved, and STARTUPDONE occurred soon after, the order might have been reversed.)

In addition, the DB_EVENT_REP_NEWMASTER event is now presented to all types of replication applications: users of either the Replication Framework or the Base Replication API. In both cases, the DB_EVENT_REP_NEWMASTER event always means that a site other than the local environment has become master.

The envid parameter to DB_ENV->rep_process_message() has been changed to be of type "int" rather than "int *", and the environment ID of a new master is presented to the application along with the DB_EVENT_REP_NEWMASTER event. Replication applications should be modified to use the DB_EVENT_REP_NEWMASTER event to determine the ID of the new master.

The envid parameter has been removed from the DB_ENV->rep_elect() method and a new event type has been added. The DB_EVENT_REP_ELECTED event is presented to the application at the site which wins an election. In the Berkeley DB 4.6 release, the normal result of a successful election is either the DB_EVENT_REP_NEWMASTER event (with the winner's environment ID), or the DB_EVENT_REP_ELECTED event. Only one of the two events will ever be delivered.

The DB_REP_NEWMASTER return code has been removed from the DB_ENV->rep_process_message() method. Replication applications should be modified to use the DB_EVENT_REP_NEWMASTER and DB_EVENT_REP_ELECTED events to determine the existence of a new master.