<!--$Id: ex_rq.so,v 1.7 2006/08/24 18:01:51 bostic Exp $--> <!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> <!--See the file LICENSE for redistribution information.--> <html> <head> <title>Berkeley DB Reference Guide: Ex_rep_base: putting it all together</title> <meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> <meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> </head> <body bgcolor=white> <table width="100%"><tr valign=top> <td><b><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Replication</dl></b></td> <td align=right><a href="../rep/ex_comm.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../xa/intro.html"><img src="../../images/next.gif" alt="Next"></a> </td></tr></table> <p align=center><b>Ex_rep_base: putting it all together</b></p> <p>Beyond simply initializing a replicated environment, an application that uses the Base replication API must set up its communication infrastructure, and then make sure that incoming messages are received and processed.</p> <p>To initialize replication, ex_rep_base creates a Berkeley DB environment and calls <a href="../../api_c/rep_transport.html">DB_ENV->rep_set_transport</a> to establish a send function. (See the main function in <b>ex_rep/base/rep_base.c</b>, including its calls to the create_env and env_init functions in <b>ex_rep/common/rep_common.c</b>.)</p> <p>ex_rep_base opens a listening socket for incoming connections and opens an outgoing connection to every machine that it knows about (that is, all the sites listed in the <b>-o</b> command line argument). Applications can structure the details of this in different ways, but ex_rep_base creates a user-level thread to listen on its socket, plus a thread to loop and handle messages on each socket, in addition to the threads needed to manage the user interface, update the database on the master, and read from the database on the client (in other words, in addition to the normal functionality of any database application).</p> <p>Once the initial threads have all been started and the communications infrastructure is initialized, the application signals that it is ready for replication and joins a replication group by calling <a href="../../api_c/rep_start.html">DB_ENV->rep_start</a>. (Again, see the main function in <b>ex_rep/base/rep_base.c</b>.)</p> <p>Note the use of the optional second argument to <a href="../../api_c/rep_start.html">DB_ENV->rep_start</a> in the client initialization code. The argument "local" is a piece of data, opaque to Berkeley DB, that will be broadcast to each member of a replication group; it allows new clients to join a replication group, without knowing the location of all its members; the new client will be contacted by the members it does not know about, who will receive the new client's contact information that was specified in "myaddr." See <a href="../../ref/rep/newsite.html">Connecting to a new site</a> for more information.</p> <p>The final piece of a replicated application is the code that loops, receives, and processes messages from a given remote environment. ex_rep_base runs one of these loops in a parallel thread for each socket connection (see the hm_loop function in <b>ex_rep/base/rep_msg.c</b>). Other applications may want to queue messages somehow and process them asynchronously, or select() on a number of sockets and either look up the correct environment ID for each or encapsulate the ID in the communications protocol.</p> <table width="100%"><tr><td><br></td><td align=right><a href="../rep/ex_comm.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../xa/intro.html"><img src="../../images/next.gif" alt="Next"></a> </td></tr></table> <p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> </body> </html>