From 780b92ada9afcf1d58085a83a0b9e6bc982203d1 Mon Sep 17 00:00:00 2001 From: Lorry Tar Creator Date: Tue, 17 Feb 2015 17:25:57 +0000 Subject: Imported from /home/lorry/working-area/delta_berkeleydb/db-6.1.23.tar.gz. --- docs/programmer_reference/rep_id.html | 77 +++++++++++++++++++---------------- 1 file changed, 43 insertions(+), 34 deletions(-) (limited to 'docs/programmer_reference/rep_id.html') diff --git a/docs/programmer_reference/rep_id.html b/docs/programmer_reference/rep_id.html index cf9b0fdc..14824fe8 100644 --- a/docs/programmer_reference/rep_id.html +++ b/docs/programmer_reference/rep_id.html @@ -14,7 +14,7 @@ -

Each database environment included in a replication group must have a -unique identifier for itself and for the other members of the -replication group. The identifiers do not need to be global, that is, -each database environment can assign local identifiers to members of -the replication group as it encounters them. For example, given three -sites: A, B and C, site A might assign the identifiers 1 and 2 to sites -B and C respectively, while site B might assign the identifiers 301 and -302 to sites A and C respectively. Note that it is not wrong to have -global identifiers, it is just not a requirement.

- Replication Manager assigns and manages environment IDs on behalf of - the application. -

-

It is the responsibility of a Base API application to label each incoming -replication message passed to DB_ENV->rep_process_message() method with the appropriate -identifier. Subsequently, Berkeley DB will label outgoing messages to the -send function with those same identifiers.

-

Negative identifiers are reserved for use by Berkeley DB, and should never be -assigned to environments by the application. Two of these reserved -identifiers are intended for application use, as follows:

+ Each database environment included in a replication group + must have a unique identifier for itself and for the other + members of the replication group. The identifiers do not need + to be global, that is, each database environment can assign + local identifiers to members of the replication group as it + encounters them. For example, given three sites: A, B and C, + site A might assign the identifiers 1 and 2 to sites B and C + respectively, while site B might assign the identifiers 301 + and 302 to sites A and C respectively. Note that it is not + wrong to have global identifiers, it is just not a + requirement. +

+

+ Replication Manager assigns and manages environment IDs on + behalf of the application. +

+

+ It is the responsibility of a Base API application to label + each incoming replication message passed to DB_ENV->rep_process_message() + method with the appropriate identifier. Subsequently, Berkeley + DB will label outgoing messages to the send + function with those same + identifiers. +

+

+ Negative identifiers are reserved for use by Berkeley DB, + and should never be assigned to environments by the + application. Two of these reserved identifiers are intended + for application use, as follows: +

@@ -66,10 +75,11 @@ identifiers are intended for application use, as follows:

-

- The DB_EID_BROADCAST identifier indicates a message should be - broadcast to all members of a replication group. -

+

+ The DB_EID_BROADCAST identifier indicates a + message should be broadcast to all members of a + replication group. +

@@ -77,10 +87,11 @@ identifiers are intended for application use, as follows:

- The DB_EID_INVALID identifier is an invalid environment ID, - and may be used to initialize environment ID variables that - are subsequently checked for validity. -

+ The DB_EID_INVALID identifier is an invalid + environment ID, and may be used to initialize + environment ID variables that are subsequently + checked for validity. +

@@ -96,9 +107,7 @@ identifiers are intended for application use, as follows:

 Next - Chapter 12.  - Berkeley DB Replication -   + Chapter 12.  Berkeley DB Replication   Home -- cgit v1.2.1