head 1.2; access; symbols RPM_4_2_1:1.1.1.4 RPM_4_2:1.1.1.4 RPM_4_1_1:1.1.1.4 RPM_4_1:1.1.1.3 RPM_4_0_5:1.1.1.2 RPM_4_0_4:1.1.1.1 RPM:1.1.1; locks; strict; comment @# @; 1.2 date 2008.01.02.09.55.29; author rse; state dead; branches; next 1.1; commitid z4cpSiAhOCXk5PLs; 1.1 date 2002.01.08.00.30.12; author rse; state Exp; branches 1.1.1.1; next ; 1.1.1.1 date 2002.01.08.00.30.12; author rse; state Exp; branches; next 1.1.1.2; 1.1.1.2 date 2003.01.18.13.49.03; author rse; state Exp; branches; next 1.1.1.3; 1.1.1.3 date 2002.01.17.20.11.42; author rse; state Exp; branches; next 1.1.1.4; 1.1.1.4 date 2003.01.18.14.05.00; author rse; state Exp; branches; next ; desc @@ 1.2 log @remove the ancient RPM 4.2.1 source tree copy @ text @ Berkeley DB Reference Guide: Building the communications infrastructure

Berkeley DB Reference Guide:
Berkeley DB Replication

Building the communications infrastructure

The replication portion of an application is typically written with one or more threads of control looping on one or more communication channels, receiving and sending messages. These threads accept messages from remote environments for the local database environment, and accept messages from the local environment for remote environments. Messages from remote environments are passed to the local database environment using the DB_ENV->rep_process_message function. Messages from the local environment are passed to the application for transmission using the callback interface specified to the DB_ENV->set_rep_transport function.

Both clients and servers establish communication channels by calling the DB_ENV->set_rep_transport function. This method specifies the send interface, a callback interface used by Berkeley DB for sending messages to other database environments in the replication group. The send interface takes an environment ID and two opaque data objects. It is the responsibility of the send interface to transmit the information in the two data objects to the database environment corresponding to the ID, with the receiving application then calling the DB_ENV->rep_process_message function to process the message.

The details of the transport mechanism are left entirely to the application; the only requirement is that the data buffer and size of each of the control and rec DBTs passed to the send function on the sending site be faithfully copied and delivered to the receiving site by means of a call to DB_ENV->rep_process_message with corresponding arguments. The DB_ENV->rep_process_message function is free-threaded; it is safe to deliver any number of messages simultaneously, and from any arbitrary thread or process in the Berkeley DB environment.

There are a number of informational returns from the DB_ENV->rep_process_message function:

DB_REP_DUPMASTER: When DB_ENV->rep_process_message returns DB_REP_DUPMASTER, it means that another database environment in the replication group also believes itself to be the master. The application should reconfigure itself as a client using the DB_ENV->rep_start function, and then call for an election by calling the DB_ENV->rep_elect function.
DB_REP_HOLDELECTION: When DB_ENV->rep_process_message returns DB_REP_HOLDELECTION, it means that another database environment in the replication group has called for an election. The application should call the DB_ENV->rep_elect function.
DB_REP_NEWMASTER: When DB_ENV->rep_process_message returns DB_REP_NEWMASTER, it means that a new master has been elected. The call will also return the local environment's ID for that master. If the ID of the master has changed, the application may need to reconfigure itself (for example, to redirect update queries to the new master rather then the old one). If the new master is the local environment, then the application must call the DB_ENV->rep_start function, and reconfigure the supporting Berkeley DB library as a replication master.
DB_REP_NEWSITE: When DB_ENV->rep_process_message returns DB_REP_NEWSITE, it means that a message from a previously unknown member of the replication group has been received. The application should reconfigure itself as necessary so it is able to send messages to this site.
DB_REP_OUTDATED: When DB_ENV->rep_process_message returns DB_REP_OUTDATED, it means that the environment has been partitioned from the master for too long a time, and the master no longer has the necessary log files to update the local client. The application should shut down, and the client should be reinitialized (see Initializing a new site for more information).

Copyright Sleepycat Software @ 1.1 log @Initial revision @ text @@ 1.1.1.1 log @Import: RPM 4.0.4 @ text @@ 1.1.1.2 log @Import: RPM 4.0.5 @ text @d1 2 a2 2 a3 1 d17 1 a17 1

The replication support in an application is typically written with one d23 1 a23 1 using the DB_ENV->rep_process_message method. Messages from the local environment d25 3 a27 4 interface specified to the DB_ENV->set_rep_transport method.

Processes establish communication channels by calling the DB_ENV->set_rep_transport method, regardless of whether they are running in client or server environments. This method specifies the send d34 1 a34 1 the DB_ENV->rep_process_message method to process the message. d37 1 a37 1 each of the control and rec DBTs passed to the send d40 1 a40 1 corresponding arguments. The DB_ENV->rep_process_message method is free-threaded; it d44 1 a44 1 DB_ENV->rep_process_message method: d48 3 a50 4 itself to be the master. The application should complete all active transactions, close all open database handles, reconfigure itself as a client using the DB_ENV->rep_start method, and then call for an election by calling the DB_ENV->rep_elect method. d53 1 a53 1 for an election. The application should call the DB_ENV->rep_elect method. d60 1 a60 1 DB_ENV->rep_start method, and reconfigure the supporting Berkeley DB library as a @ 1.1.1.3 log @Import: RPM 4.1 @ text @d1 2 a2 2 d4 1 d18 1 a18 1

The replication portion of an application is typically written with one d24 1 a24 1 using the DB_ENV->rep_process_message function. Messages from the local environment d26 4 a29 3 interface specified to the DB_ENV->set_rep_transport function.

Both clients and servers establish communication channels by calling the DB_ENV->set_rep_transport function. This method specifies the send d36 1 a36 1 the DB_ENV->rep_process_message function to process the message. d39 1 a39 1 each of the control and rec DBTs passed to the send d42 1 a42 1 corresponding arguments. The DB_ENV->rep_process_message function is free-threaded; it d46 1 a46 1 DB_ENV->rep_process_message function: d50 4 a53 3 itself to be the master. The application should reconfigure itself as a client using the DB_ENV->rep_start function, and then call for an election by calling the DB_ENV->rep_elect function. d56 1 a56 1 for an election. The application should call the DB_ENV->rep_elect function. d63 1 a63 1 DB_ENV->rep_start function, and reconfigure the supporting Berkeley DB library as a @ 1.1.1.4 log @Import: RPM 4.1.1 @ text @d1 2 a2 2 a3 1 d17 1 a17 1

Berkeley DB Reference Guide:Berkeley DB Replication

Building the communications infrastructure

Berkeley DB Reference Guide:
Berkeley DB Replication