mirror of
https://github.com/MariaDB/server.git
synced 2026-05-14 19:07:15 +02:00
BDB 4.1.24
BitKeeper/deleted/.del-ex_access.wpj~3df6ae8c99bf7c5f: Delete: bdb/build_vxworks/ex_access/ex_access.wpj BitKeeper/deleted/.del-ex_btrec.wpj~a7622f1c6f432dc6: Delete: bdb/build_vxworks/ex_btrec/ex_btrec.wpj BitKeeper/deleted/.del-ex_dbclient.wpj~7345440f3b204cdd: Delete: bdb/build_vxworks/ex_dbclient/ex_dbclient.wpj BitKeeper/deleted/.del-ex_env.wpj~fbe1ab10b04e8b74: Delete: bdb/build_vxworks/ex_env/ex_env.wpj BitKeeper/deleted/.del-ex_mpool.wpj~4479cfd5c45f327d: Delete: bdb/build_vxworks/ex_mpool/ex_mpool.wpj BitKeeper/deleted/.del-ex_tpcb.wpj~f78093006e14bf41: Delete: bdb/build_vxworks/ex_tpcb/ex_tpcb.wpj BitKeeper/deleted/.del-db_buildall.dsp~bd749ff6da11682: Delete: bdb/build_win32/db_buildall.dsp BitKeeper/deleted/.del-cxx_app.cpp~ad8df8e0791011ed: Delete: bdb/cxx/cxx_app.cpp BitKeeper/deleted/.del-cxx_log.cpp~a50ff3118fe06952: Delete: bdb/cxx/cxx_log.cpp BitKeeper/deleted/.del-cxx_table.cpp~ecd751e79b055556: Delete: bdb/cxx/cxx_table.cpp BitKeeper/deleted/.del-namemap.txt~796a3acd3885d8fd: Delete: bdb/cxx/namemap.txt BitKeeper/deleted/.del-Design.fileop~3ca4da68f1727373: Delete: bdb/db/Design.fileop BitKeeper/deleted/.del-db185_int.h~61bee3736e7959ef: Delete: bdb/db185/db185_int.h BitKeeper/deleted/.del-acconfig.h~411e8854d67ad8b5: Delete: bdb/dist/acconfig.h BitKeeper/deleted/.del-mutex.m4~a13383cde18a64e1: Delete: bdb/dist/aclocal/mutex.m4 BitKeeper/deleted/.del-options.m4~b9d0ca637213750a: Delete: bdb/dist/aclocal/options.m4 BitKeeper/deleted/.del-programs.m4~3ce7890b47732b30: Delete: bdb/dist/aclocal/programs.m4 BitKeeper/deleted/.del-tcl.m4~f944e2db93c3b6db: Delete: bdb/dist/aclocal/tcl.m4 BitKeeper/deleted/.del-types.m4~59cae158c9a32cff: Delete: bdb/dist/aclocal/types.m4 BitKeeper/deleted/.del-script~d38f6d3a4f159cb4: Delete: bdb/dist/build/script BitKeeper/deleted/.del-configure.in~ac795a92c8fe049c: Delete: bdb/dist/configure.in BitKeeper/deleted/.del-ltconfig~66bbd007d8024af: Delete: bdb/dist/ltconfig BitKeeper/deleted/.del-rec_ctemp~a28554362534f00a: Delete: bdb/dist/rec_ctemp BitKeeper/deleted/.del-s_tcl~2ffe4326459fcd9f: Delete: bdb/dist/s_tcl BitKeeper/deleted/.del-.IGNORE_ME~d8148b08fa7d5d15: Delete: bdb/dist/template/.IGNORE_ME BitKeeper/deleted/.del-btree.h~179f2aefec1753d: Delete: bdb/include/btree.h BitKeeper/deleted/.del-cxx_int.h~6b649c04766508f8: Delete: bdb/include/cxx_int.h BitKeeper/deleted/.del-db.src~6b433ae615b16a8d: Delete: bdb/include/db.src BitKeeper/deleted/.del-db_185.h~ad8b373d9391d35c: Delete: bdb/include/db_185.h BitKeeper/deleted/.del-db_am.h~a714912b6b75932f: Delete: bdb/include/db_am.h BitKeeper/deleted/.del-db_cxx.h~fcafadf45f5d19e9: Delete: bdb/include/db_cxx.h BitKeeper/deleted/.del-db_dispatch.h~6844f20f7eb46904: Delete: bdb/include/db_dispatch.h BitKeeper/deleted/.del-db_int.src~419a3f48b6a01da7: Delete: bdb/include/db_int.src BitKeeper/deleted/.del-db_join.h~76f9747a42c3399a: Delete: bdb/include/db_join.h BitKeeper/deleted/.del-db_page.h~e302ca3a4db3abdc: Delete: bdb/include/db_page.h BitKeeper/deleted/.del-db_server_int.h~e1d20b6ba3bca1ab: Delete: bdb/include/db_server_int.h BitKeeper/deleted/.del-db_shash.h~5fbf2d696fac90f3: Delete: bdb/include/db_shash.h BitKeeper/deleted/.del-db_swap.h~1e60887550864a59: Delete: bdb/include/db_swap.h BitKeeper/deleted/.del-db_upgrade.h~c644eee73701fc8d: Delete: bdb/include/db_upgrade.h BitKeeper/deleted/.del-db_verify.h~b8d6c297c61f342e: Delete: bdb/include/db_verify.h BitKeeper/deleted/.del-debug.h~dc2b4f2cf27ccebc: Delete: bdb/include/debug.h BitKeeper/deleted/.del-hash.h~2aaa548b28882dfb: Delete: bdb/include/hash.h BitKeeper/deleted/.del-lock.h~a761c1b7de57b77f: Delete: bdb/include/lock.h BitKeeper/deleted/.del-log.h~ff20184238e35e4d: Delete: bdb/include/log.h BitKeeper/deleted/.del-mp.h~7e317597622f3411: Delete: bdb/include/mp.h BitKeeper/deleted/.del-mutex.h~d3ae7a2977a68137: Delete: bdb/include/mutex.h BitKeeper/deleted/.del-os.h~91867cc8757cd0e3: Delete: bdb/include/os.h BitKeeper/deleted/.del-os_jump.h~e1b939fa5151d4be: Delete: bdb/include/os_jump.h BitKeeper/deleted/.del-qam.h~6fad0c1b5723d597: Delete: bdb/include/qam.h BitKeeper/deleted/.del-queue.h~4c72c0826c123d5: Delete: bdb/include/queue.h BitKeeper/deleted/.del-region.h~513fe04d977ca0fc: Delete: bdb/include/region.h BitKeeper/deleted/.del-shqueue.h~525fc3e6c2025c36: Delete: bdb/include/shqueue.h BitKeeper/deleted/.del-tcl_db.h~c536fd61a844f23f: Delete: bdb/include/tcl_db.h BitKeeper/deleted/.del-txn.h~c8d94b221ec147e4: Delete: bdb/include/txn.h BitKeeper/deleted/.del-xa.h~ecc466493aae9d9a: Delete: bdb/include/xa.h BitKeeper/deleted/.del-DbRecoveryInit.java~756b52601a0b9023: Delete: bdb/java/src/com/sleepycat/db/DbRecoveryInit.java BitKeeper/deleted/.del-DbTxnRecover.java~74607cba7ab89d6d: Delete: bdb/java/src/com/sleepycat/db/DbTxnRecover.java BitKeeper/deleted/.del-lock_conflict.c~fc5e0f14cf597a2b: Delete: bdb/lock/lock_conflict.c BitKeeper/deleted/.del-log.src~53ac9e7b5cb023f2: Delete: bdb/log/log.src BitKeeper/deleted/.del-log_findckp.c~24287f008916e81f: Delete: bdb/log/log_findckp.c BitKeeper/deleted/.del-log_rec.c~d51711f2cac09297: Delete: bdb/log/log_rec.c BitKeeper/deleted/.del-log_register.c~b40bb4efac75ca15: Delete: bdb/log/log_register.c BitKeeper/deleted/.del-Design~b3d0f179f2767b: Delete: bdb/mp/Design BitKeeper/deleted/.del-os_finit.c~95dbefc6fe79b26c: Delete: bdb/os/os_finit.c BitKeeper/deleted/.del-os_abs.c~df95d1e7db81924: Delete: bdb/os_vxworks/os_abs.c BitKeeper/deleted/.del-os_finit.c~803b484bdb9d0122: Delete: bdb/os_vxworks/os_finit.c BitKeeper/deleted/.del-os_map.c~3a6d7926398b76d3: Delete: bdb/os_vxworks/os_map.c BitKeeper/deleted/.del-os_finit.c~19a227c6d3c78ad: Delete: bdb/os_win32/os_finit.c BitKeeper/deleted/.del-log-corruption.patch~1cf2ecc7c6408d5d: Delete: bdb/patches/log-corruption.patch BitKeeper/deleted/.del-Btree.pm~af6d0c5eaed4a98e: Delete: bdb/perl.BerkeleyDB/BerkeleyDB/Btree.pm BitKeeper/deleted/.del-BerkeleyDB.pm~7244036d4482643: Delete: bdb/perl.BerkeleyDB/BerkeleyDB.pm BitKeeper/deleted/.del-BerkeleyDB.pod~e7b18fd6132448e3: Delete: bdb/perl.BerkeleyDB/BerkeleyDB.pod BitKeeper/deleted/.del-Hash.pm~10292a26c06a5c95: Delete: bdb/perl.BerkeleyDB/BerkeleyDB/Hash.pm BitKeeper/deleted/.del-BerkeleyDB.pod.P~79f76a1495eda203: Delete: bdb/perl.BerkeleyDB/BerkeleyDB.pod.P BitKeeper/deleted/.del-BerkeleyDB.xs~80c99afbd98e392c: Delete: bdb/perl.BerkeleyDB/BerkeleyDB.xs BitKeeper/deleted/.del-Changes~729c1891efa60de9: Delete: bdb/perl.BerkeleyDB/Changes BitKeeper/deleted/.del-MANIFEST~63a1e34aecf157a0: Delete: bdb/perl.BerkeleyDB/MANIFEST BitKeeper/deleted/.del-Makefile.PL~c68797707d8df87a: Delete: bdb/perl.BerkeleyDB/Makefile.PL BitKeeper/deleted/.del-README~5f2f579b1a241407: Delete: bdb/perl.BerkeleyDB/README BitKeeper/deleted/.del-Todo~dca3c66c193adda9: Delete: bdb/perl.BerkeleyDB/Todo BitKeeper/deleted/.del-config.in~ae81681e450e0999: Delete: bdb/perl.BerkeleyDB/config.in BitKeeper/deleted/.del-dbinfo~28ad67d83be4f68e: Delete: bdb/perl.BerkeleyDB/dbinfo BitKeeper/deleted/.del-mkconsts~543ab60669c7a04e: Delete: bdb/perl.BerkeleyDB/mkconsts BitKeeper/deleted/.del-mkpod~182c0ca54e439afb: Delete: bdb/perl.BerkeleyDB/mkpod BitKeeper/deleted/.del-5.004~e008cb5a48805543: Delete: bdb/perl.BerkeleyDB/patches/5.004 BitKeeper/deleted/.del-irix_6_5.pl~61662bb08afcdec8: Delete: bdb/perl.BerkeleyDB/hints/irix_6_5.pl BitKeeper/deleted/.del-solaris.pl~6771e7182394e152: Delete: bdb/perl.BerkeleyDB/hints/solaris.pl BitKeeper/deleted/.del-typemap~783b8f5295b05f3d: Delete: bdb/perl.BerkeleyDB/typemap BitKeeper/deleted/.del-5.004_01~6081ce2fff7b0bc: Delete: bdb/perl.BerkeleyDB/patches/5.004_01 BitKeeper/deleted/.del-5.004_02~87214eac35ad9e6: Delete: bdb/perl.BerkeleyDB/patches/5.004_02 BitKeeper/deleted/.del-5.004_03~9a672becec7cb40f: Delete: bdb/perl.BerkeleyDB/patches/5.004_03 BitKeeper/deleted/.del-5.004_04~e326cb51af09d154: Delete: bdb/perl.BerkeleyDB/patches/5.004_04 BitKeeper/deleted/.del-5.004_05~7ab457a1e41a92fe: Delete: bdb/perl.BerkeleyDB/patches/5.004_05 BitKeeper/deleted/.del-5.005~f9e2d59b5964cd4b: Delete: bdb/perl.BerkeleyDB/patches/5.005 BitKeeper/deleted/.del-5.005_01~3eb9fb7b5842ea8e: Delete: bdb/perl.BerkeleyDB/patches/5.005_01 BitKeeper/deleted/.del-5.005_02~67477ce0bef717cb: Delete: bdb/perl.BerkeleyDB/patches/5.005_02 BitKeeper/deleted/.del-5.005_03~c4c29a1fb21e290a: Delete: bdb/perl.BerkeleyDB/patches/5.005_03 BitKeeper/deleted/.del-5.6.0~e1fb9897d124ee22: Delete: bdb/perl.BerkeleyDB/patches/5.6.0 BitKeeper/deleted/.del-btree.t~e4a1a3c675ddc406: Delete: bdb/perl.BerkeleyDB/t/btree.t BitKeeper/deleted/.del-db-3.0.t~d2c60991d84558f2: Delete: bdb/perl.BerkeleyDB/t/db-3.0.t BitKeeper/deleted/.del-db-3.1.t~6ee88cd13f55e018: Delete: bdb/perl.BerkeleyDB/t/db-3.1.t BitKeeper/deleted/.del-db-3.2.t~f73b6461f98fd1cf: Delete: bdb/perl.BerkeleyDB/t/db-3.2.t BitKeeper/deleted/.del-destroy.t~cc6a2ae1980a2ecd: Delete: bdb/perl.BerkeleyDB/t/destroy.t BitKeeper/deleted/.del-env.t~a8604a4499c4bd07: Delete: bdb/perl.BerkeleyDB/t/env.t BitKeeper/deleted/.del-examples.t~2571b77c3cc75574: Delete: bdb/perl.BerkeleyDB/t/examples.t BitKeeper/deleted/.del-examples.t.T~8228bdd75ac78b88: Delete: bdb/perl.BerkeleyDB/t/examples.t.T BitKeeper/deleted/.del-examples3.t.T~66a186897a87026d: Delete: bdb/perl.BerkeleyDB/t/examples3.t.T BitKeeper/deleted/.del-examples3.t~fe3822ba2f2d7f83: Delete: bdb/perl.BerkeleyDB/t/examples3.t BitKeeper/deleted/.del-filter.t~f87b045c1b708637: Delete: bdb/perl.BerkeleyDB/t/filter.t BitKeeper/deleted/.del-hash.t~616bfb4d644de3a3: Delete: bdb/perl.BerkeleyDB/t/hash.t BitKeeper/deleted/.del-join.t~29fc39f74a83ca22: Delete: bdb/perl.BerkeleyDB/t/join.t BitKeeper/deleted/.del-mldbm.t~31f5015341eea040: Delete: bdb/perl.BerkeleyDB/t/mldbm.t BitKeeper/deleted/.del-queue.t~8f338034ce44a641: Delete: bdb/perl.BerkeleyDB/t/queue.t BitKeeper/deleted/.del-recno.t~d4ddbd3743add63e: Delete: bdb/perl.BerkeleyDB/t/recno.t BitKeeper/deleted/.del-strict.t~6885cdd2ea71ca2d: Delete: bdb/perl.BerkeleyDB/t/strict.t BitKeeper/deleted/.del-subdb.t~aab62a5d5864c603: Delete: bdb/perl.BerkeleyDB/t/subdb.t BitKeeper/deleted/.del-txn.t~65033b8558ae1216: Delete: bdb/perl.BerkeleyDB/t/txn.t BitKeeper/deleted/.del-unknown.t~f3710458682665e1: Delete: bdb/perl.BerkeleyDB/t/unknown.t BitKeeper/deleted/.del-Changes~436f74a5c414c65b: Delete: bdb/perl.DB_File/Changes BitKeeper/deleted/.del-DB_File.pm~ae0951c6c7665a82: Delete: bdb/perl.DB_File/DB_File.pm BitKeeper/deleted/.del-DB_File.xs~89e49a0b5556f1d8: Delete: bdb/perl.DB_File/DB_File.xs BitKeeper/deleted/.del-DB_File_BS~290fad5dbbb87069: Delete: bdb/perl.DB_File/DB_File_BS BitKeeper/deleted/.del-MANIFEST~90ee581572bdd4ac: Delete: bdb/perl.DB_File/MANIFEST BitKeeper/deleted/.del-Makefile.PL~ac0567bb5a377e38: Delete: bdb/perl.DB_File/Makefile.PL BitKeeper/deleted/.del-README~77e924a5a9bae6b3: Delete: bdb/perl.DB_File/README BitKeeper/deleted/.del-config.in~ab4c2792b86a810b: Delete: bdb/perl.DB_File/config.in BitKeeper/deleted/.del-dbinfo~461c43b30fab2cb: Delete: bdb/perl.DB_File/dbinfo BitKeeper/deleted/.del-dynixptx.pl~50dcddfae25d17e9: Delete: bdb/perl.DB_File/hints/dynixptx.pl BitKeeper/deleted/.del-typemap~55cffb3288a9e587: Delete: bdb/perl.DB_File/typemap BitKeeper/deleted/.del-version.c~a4df0e646f8b3975: Delete: bdb/perl.DB_File/version.c BitKeeper/deleted/.del-5.004_01~d6830d0082702af7: Delete: bdb/perl.DB_File/patches/5.004_01 BitKeeper/deleted/.del-5.004_02~78b082dc80c91031: Delete: bdb/perl.DB_File/patches/5.004_02 BitKeeper/deleted/.del-5.004~4411ec2e3c9e008b: Delete: bdb/perl.DB_File/patches/5.004 BitKeeper/deleted/.del-sco.pl~1e795fe14fe4dcfe: Delete: bdb/perl.DB_File/hints/sco.pl BitKeeper/deleted/.del-5.004_03~33f274648b160d95: Delete: bdb/perl.DB_File/patches/5.004_03 BitKeeper/deleted/.del-5.004_04~8f3d1b3cf18bb20a: Delete: bdb/perl.DB_File/patches/5.004_04 BitKeeper/deleted/.del-5.004_05~9c0f02e7331e142: Delete: bdb/perl.DB_File/patches/5.004_05 BitKeeper/deleted/.del-5.005~c2108cb2e3c8d951: Delete: bdb/perl.DB_File/patches/5.005 BitKeeper/deleted/.del-5.005_01~3b45e9673afc4cfa: Delete: bdb/perl.DB_File/patches/5.005_01 BitKeeper/deleted/.del-5.005_02~9fe5766bb02a4522: Delete: bdb/perl.DB_File/patches/5.005_02 BitKeeper/deleted/.del-5.005_03~ffa1c38c19ae72ea: Delete: bdb/perl.DB_File/patches/5.005_03 BitKeeper/deleted/.del-5.6.0~373be3a5ce47be85: Delete: bdb/perl.DB_File/patches/5.6.0 BitKeeper/deleted/.del-db-btree.t~3231595a1c241eb3: Delete: bdb/perl.DB_File/t/db-btree.t BitKeeper/deleted/.del-db-hash.t~7c4ad0c795c7fad2: Delete: bdb/perl.DB_File/t/db-hash.t BitKeeper/deleted/.del-db-recno.t~6c2d3d80b9ba4a50: Delete: bdb/perl.DB_File/t/db-recno.t BitKeeper/deleted/.del-db_server.sed~cdb00ebcd48a64e2: Delete: bdb/rpc_server/db_server.sed BitKeeper/deleted/.del-db_server_proc.c~d46c8f409c3747f4: Delete: bdb/rpc_server/db_server_proc.c BitKeeper/deleted/.del-db_server_svc.sed~3f5e59f334fa4607: Delete: bdb/rpc_server/db_server_svc.sed BitKeeper/deleted/.del-db_server_util.c~a809f3a4629acda: Delete: bdb/rpc_server/db_server_util.c BitKeeper/deleted/.del-log.tcl~ff1b41f1355b97d7: Delete: bdb/test/log.tcl BitKeeper/deleted/.del-mpool.tcl~b0df4dc1b04db26c: Delete: bdb/test/mpool.tcl BitKeeper/deleted/.del-mutex.tcl~52fd5c73a150565: Delete: bdb/test/mutex.tcl BitKeeper/deleted/.del-txn.tcl~c4ff071550b5446e: Delete: bdb/test/txn.tcl BitKeeper/deleted/.del-README~e800a12a5392010a: Delete: bdb/test/upgrade/README BitKeeper/deleted/.del-pack-2.6.6.pl~89d5076d758d3e98: Delete: bdb/test/upgrade/generate-2.X/pack-2.6.6.pl BitKeeper/deleted/.del-test-2.6.patch~4a52dc83d447547b: Delete: bdb/test/upgrade/generate-2.X/test-2.6.patch
This commit is contained in:
unknown
parent
b8798d25ab
commit
155e78f014
1191 changed files with 170446 additions and 57453 deletions
|
|
@ -1,52 +1,52 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
|
||||
<META NAME="GENERATOR" CONTENT="Mozilla/4.08 [en] (X11; I; FreeBSD 3.3-RELEASE i386) [Netscape]">
|
||||
</HEAD>
|
||||
<BODY>
|
||||
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
||||
<meta name="GENERATOR" content="Mozilla/4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) [Netscape]">
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<CENTER>
|
||||
<H1>
|
||||
Client/Server Interface for Berkeley DB</H1></CENTER>
|
||||
<center>
|
||||
<h1>
|
||||
Client/Server Interface for Berkeley DB</h1></center>
|
||||
|
||||
<CENTER><I>Susan LoVerso</I>
|
||||
<BR><I>sue@sleepycat.com</I>
|
||||
<BR><I>Rev 1.3</I>
|
||||
<BR><I>1999 Nov 29</I></CENTER>
|
||||
<center><i>Susan LoVerso</i>
|
||||
<br><i>sue@sleepycat.com</i>
|
||||
<br><i>Rev 1.3</i>
|
||||
<br><i>1999 Nov 29</i></center>
|
||||
|
||||
<P>We provide an interface allowing client/server access to Berkeley DB.
|
||||
<p>We provide an interface allowing client/server access to Berkeley DB.
|
||||
Our goal is to provide a client and server library to allow users to separate
|
||||
the functionality of their applications yet still have access to the full
|
||||
benefits of Berkeley DB. The goal is to provide a totally seamless
|
||||
interface with minimal modification to existing applications as well.
|
||||
<P>The client/server interface for Berkeley DB can be broken up into several
|
||||
<p>The client/server interface for Berkeley DB can be broken up into several
|
||||
layers. At the lowest level there is the transport mechanism to send
|
||||
out the messages over the network. Above that layer is the messaging
|
||||
layer to interpret what comes over the wire, and bundle/unbundle message
|
||||
contents. The next layer is Berkeley DB itself.
|
||||
<P>The transport layer uses ONC RPC (RFC 1831) and XDR (RFC 1832).
|
||||
<p>The transport layer uses ONC RPC (RFC 1831) and XDR (RFC 1832).
|
||||
We declare our message types and operations supported by our program and
|
||||
the RPC library and utilities pretty much take care of the rest.
|
||||
The
|
||||
<I>rpcgen</I> program generates all of the low level code needed.
|
||||
<i>rpcgen</i> program generates all of the low level code needed.
|
||||
We need to define both sides of the RPC.
|
||||
<BR>
|
||||
<H2>
|
||||
<A NAME="DB Modifications"></A>DB Modifications</H2>
|
||||
<br>
|
||||
<h2>
|
||||
<a NAME="DB Modifications"></a>DB Modifications</h2>
|
||||
To achieve the goal of a seamless interface, it is necessary to impose
|
||||
a constraint on the application. That constraint is simply that all database
|
||||
access must be done through an open environment. I.e. this model
|
||||
does not support standalone databases. The reason for this constraint
|
||||
is so that we have an environment structure internally to store our connection
|
||||
to the server. Imposing this constraint means that we can provide
|
||||
the seamless interface just by adding a single environment method: <A HREF="../docs/api_c/env_set_server.html">DBENV->set_server()</A>.
|
||||
<P>The planned interface for this method is:
|
||||
<PRE>DBENV->set_server(dbenv, /* DB_ENV structure */
|
||||
the seamless interface just by adding a single environment method: <a href="../docs/api_c/env_set_rpc_server.html">DBENV->set_rpc_server()</a>.
|
||||
<p>The planned interface for this method is:
|
||||
<pre>DBENV->set_rpc_server(dbenv, /* DB_ENV structure */
|
||||
hostname /* Host of server */
|
||||
cl_timeout, /* Client timeout (sec) */
|
||||
srv_timeout,/* Server timeout (sec) */
|
||||
flags); /* Flags: unused */</PRE>
|
||||
flags); /* Flags: unused */</pre>
|
||||
This new method takes the hostname of the server, establishes our connection
|
||||
and an environment on the server. If a server timeout is specified,
|
||||
then we send that to the server as well (and the server may or may not
|
||||
|
|
@ -61,30 +61,30 @@ is currently unused, but exists because we always need to have a placeholder
|
|||
for flags and it would be used for specifying authentication desired (were
|
||||
we to provide an authentication scheme at some point) or other uses not
|
||||
thought of yet!
|
||||
<P>This client code is part of the monolithic DB library. The user
|
||||
accesses the client functions via a new flag to <A HREF="../docs/api_c/db_env_create.html">db_env_create()</A>.
|
||||
<p>This client code is part of the monolithic DB library. The user
|
||||
accesses the client functions via a new flag to <a href="../docs/api_c/db_env_create.html">db_env_create()</a>.
|
||||
That flag is DB_CLIENT. By using this flag the user indicates they
|
||||
want to have the client methods rather than the standard methods for the
|
||||
environment. Also by issuing this flag, the user needs to connect
|
||||
to the server via the <A HREF="../docs/api_c/env_set_server.html">DBENV->set_server()</A>
|
||||
to the server via the <a href="../docs/api_c/env_set_rpc_server.html">DBENV->set_rpc_server()</a>
|
||||
method.
|
||||
<P>We need two new fields in the <I>DB_ENV </I>structure. One is
|
||||
<p>We need two new fields in the <i>DB_ENV </i>structure. One is
|
||||
the socket descriptor to communicate to the server, the other field is
|
||||
the client identifier the server gives to us. The <I>DB, </I>and<I>
|
||||
DBC </I>only need one additional field, the client identifier. The
|
||||
<I>DB_TXN</I>
|
||||
structure does not need modification, we are overloading the <I>txn_id
|
||||
</I>field.
|
||||
<H2>
|
||||
Issues</H2>
|
||||
the client identifier the server gives to us. The <i>DB, </i>and<i>
|
||||
DBC </i>only need one additional field, the client identifier. The
|
||||
<i>DB_TXN</i>
|
||||
structure does not need modification, we are overloading the <i>txn_id
|
||||
</i>field.
|
||||
<h2>
|
||||
Issues</h2>
|
||||
We need to figure out what to do in case of client and server crashes.
|
||||
Both the client library and the server program are stateful. They
|
||||
both consume local resources during the lifetime of the connection.
|
||||
Should one end drop that connection, the other side needs to release those
|
||||
resources.
|
||||
<P>If the server crashes, then the client will get an error back.
|
||||
<p>If the server crashes, then the client will get an error back.
|
||||
I have chosen to implement time-outs on the client side, using a default
|
||||
or allowing the application to specify one through the <A HREF="../docs/api_c/env_set_server.html">DBENV->set_server()</A>
|
||||
or allowing the application to specify one through the <a href="../docs/api_c/env_set_rpc_server.html">DBENV->set_rpc_server()</a>
|
||||
method. Either the current operation will time-out waiting for the
|
||||
reply or the next operation called will time out (or get back some other
|
||||
kind of error regarding the server's non-existence). In any case,
|
||||
|
|
@ -102,65 +102,65 @@ on recover. The client can then re-establish its connection and begin
|
|||
again. This is effectively like beginning over. The client
|
||||
cannot use ID's from its previous connection to the server. However,
|
||||
if recovery is run, then consistency is assured.
|
||||
<P>If the client crashes, the server needs to somehow figure this out.
|
||||
<p>If the client crashes, the server needs to somehow figure this out.
|
||||
The server is just sitting there waiting for a request to come in.
|
||||
A server must be able to time-out a client. Similar to ftpd, if a
|
||||
connection is idle for N seconds, then the server decides the client is
|
||||
dead and releases that client's resources, aborting any open transactions,
|
||||
closing any open databases and environments. The server timing
|
||||
out a client is not a trivial issue however. The generated function
|
||||
for the server just calls <I>svc_run()</I>. The server code I write
|
||||
for the server just calls <i>svc_run()</i>. The server code I write
|
||||
contains procedures to do specific things. We do not have access
|
||||
to the code calling <I>select()</I>. Timing out the select is not
|
||||
to the code calling <i>select()</i>. Timing out the select is not
|
||||
good enough even if we could do so. We want to time-out idle environments,
|
||||
not simply cause a time-out if the server is idle a while. See the
|
||||
discussion of the <A HREF="#The Server Program">server program</A> for
|
||||
discussion of the <a href="#The Server Program">server program</a> for
|
||||
a description of how we accomplish this.
|
||||
<P>Since rpcgen generates the main() function of the server, I do not yet
|
||||
<p>Since rpcgen generates the main() function of the server, I do not yet
|
||||
know how we are going to have the server multi-threaded or multi-process
|
||||
without changing the generated code. The RPC book indicates that
|
||||
the only way to accomplish this is through modifying the generated code
|
||||
in the server. <B>For the moment we will ignore this issue while
|
||||
we get the core server working, as it is only a performance issue.</B>
|
||||
<P>We do not do any security or authentication. Someone could get
|
||||
in the server. <b>For the moment we will ignore this issue while
|
||||
we get the core server working, as it is only a performance issue.</b>
|
||||
<p>We do not do any security or authentication. Someone could get
|
||||
the code and modify it to spoof messages, trick the server, etc.
|
||||
RPC has some amount of authentication built into it. I haven't yet
|
||||
looked into it much to know if we want to use it or just point a user at
|
||||
it. The changes to the client code are fairly minor, the changes
|
||||
to our server procs are fairly minor. We would have to add code to
|
||||
a <I>sed</I> script or <I>awk</I> script to change the generated server
|
||||
a <i>sed</i> script or <i>awk</i> script to change the generated server
|
||||
code (yet again) in the dispatch routine to perform authentication.
|
||||
<P>We will need to get an official program number from Sun. We can
|
||||
get this by sending mail to <I>rpc@sun.com</I> and presumably at some point
|
||||
<p>We will need to get an official program number from Sun. We can
|
||||
get this by sending mail to <i>rpc@sun.com</i> and presumably at some point
|
||||
they will send us back a program number that we will encode into our XDR
|
||||
description file. Until we release this we can use a program number
|
||||
in the "user defined" number space.
|
||||
<BR>
|
||||
<H2>
|
||||
<A NAME="The Server Program"></A>The Server Program</H2>
|
||||
<br>
|
||||
<h2>
|
||||
<a NAME="The Server Program"></a>The Server Program</h2>
|
||||
The server is a standalone program that the user builds and runs, probably
|
||||
as a daemon like process. This program is linked against the Berkeley
|
||||
DB library and the RPC library (which is part of the C library on my FreeBSD
|
||||
machine, others may have/need <I>-lrpclib</I>). The server basically
|
||||
machine, others may have/need <i>-lrpclib</i>). The server basically
|
||||
is a slave to the client process. All messages from the client are
|
||||
synchronous and two-way. The server handles messages one at a time,
|
||||
and sends a reply back before getting another message. There are
|
||||
no asynchronous messages generated by the server to the client.
|
||||
<P>We have made a choice to modify the generated code for the server.
|
||||
<p>We have made a choice to modify the generated code for the server.
|
||||
The changes will be minimal, generally calling functions we write, that
|
||||
are in other source files. The first change is adding a call to our
|
||||
time-out function as described below. The second change is changing
|
||||
the name of the generated <I>main()</I> function to <I>__dbsrv_main()</I>,
|
||||
and adding our own <I>main()</I> function so that we can parse options,
|
||||
and set up other initialization we require. I have a <I>sed</I> script
|
||||
the name of the generated <i>main()</i> function to <i>__dbsrv_main()</i>,
|
||||
and adding our own <i>main()</i> function so that we can parse options,
|
||||
and set up other initialization we require. I have a <i>sed</i> script
|
||||
that is run from the distribution scripts that massages the generated code
|
||||
to make these minor changes.
|
||||
<P>Primarily the code needed for the server is the collection of the specified
|
||||
<p>Primarily the code needed for the server is the collection of the specified
|
||||
RPC functions. Each function receives the structure indicated, and
|
||||
our code takes out what it needs and passes the information into DB itself.
|
||||
The server needs to maintain a translation table for identifiers that we
|
||||
pass back to the client for the environment, transaction and database handles.
|
||||
<P>The table that the server maintains, assuming one client per server
|
||||
<p>The table that the server maintains, assuming one client per server
|
||||
process/thread, should contain the handle to the environment, database
|
||||
or transaction, a link to maintain parent/child relationships between transactions,
|
||||
or databases and cursors, this handle's identifier, a type so that we can
|
||||
|
|
@ -169,7 +169,7 @@ handle's environment entry (for time out/activity purposes). The
|
|||
table contains, in entries used by environments, a time-out value and an
|
||||
activity time stamp. Its use is described below for timing out idle
|
||||
clients.
|
||||
<P>Here is how we time out clients in the server. We have to modify
|
||||
<p>Here is how we time out clients in the server. We have to modify
|
||||
the generated server code, but only to add one line during the dispatch
|
||||
function to run the time-out function. The call is made right before
|
||||
the return of the dispatch function, after the reply is sent to the client,
|
||||
|
|
@ -181,16 +181,16 @@ we know we do not need to run through the list of open handles. If
|
|||
the hint is expired, then we go through the list of open environment handles,
|
||||
and if they are past their expiration, then we close them and clean up.
|
||||
If they are not, we set up the hint for the next time.
|
||||
<P>Each entry in the open handle table has a pointer back to its environment's
|
||||
<p>Each entry in the open handle table has a pointer back to its environment's
|
||||
entry. Every operation within this environment can then update the
|
||||
single environment activity record. Every environment can have a
|
||||
different time-out. The <A HREF="../docs/api_c/env_set_server.html">DBENV->set_server
|
||||
</A>call
|
||||
different time-out. The <a href="../docs/api_c/env_set_rpc_server.html">DBENV->set_rpc_server
|
||||
</a>call
|
||||
takes a server time-out value. If this value is 0 then a default
|
||||
(currently 5 minutes) is used. This time-out value is only a hint
|
||||
to the server. It may choose to disregard this value or set the time-out
|
||||
based on its own implementation.
|
||||
<P>For completeness, the flaws of this time-out implementation should be
|
||||
<p>For completeness, the flaws of this time-out implementation should be
|
||||
pointed out. First, it is possible that a client could crash with
|
||||
open handles, and no other requests come in to the server. Therefore
|
||||
the time-out function never gets run and those resources are not released
|
||||
|
|
@ -205,222 +205,222 @@ of 1 minute. If this environment becomes idle (and other operations
|
|||
are going on), the time-out function will not release that environment
|
||||
until the original 5 minute hint expires. This is not a problem since
|
||||
the resources will eventually be released.
|
||||
<P>On a similar note, if a client crashes during an RPC, our reply generates
|
||||
a SIGPIPE, and our server crashes unless we catch it. Using <I>signal(SIGPIPE,
|
||||
SIG_IGN) </I>we can ignore it, and the server will go on. This is
|
||||
a call in our <I>main()</I> function that we write. Eventually
|
||||
<p>On a similar note, if a client crashes during an RPC, our reply generates
|
||||
a SIGPIPE, and our server crashes unless we catch it. Using <i>signal(SIGPIPE,
|
||||
SIG_IGN) </i>we can ignore it, and the server will go on. This is
|
||||
a call in our <i>main()</i> function that we write. Eventually
|
||||
this client's handles would be timed out as described above. We need
|
||||
this only for the unfortunate window of a client crashing during the RPC.
|
||||
<P>The options below are primarily for control of the program itself,.
|
||||
<p>The options below are primarily for control of the program itself,.
|
||||
Details relating to databases and environments should be passed from the
|
||||
client to the server, since the server can serve many clients, many environments
|
||||
and many databases. Therefore it makes more sense for the client
|
||||
to set the cache size of its own environment, rather than setting a default
|
||||
cachesize on the server that applies as a blanket to any environment it
|
||||
may be called upon to open. Options are:
|
||||
<UL>
|
||||
<LI>
|
||||
<B>-t </B> to set the default time-out given to an environment.</LI>
|
||||
<ul>
|
||||
<li>
|
||||
<b>-t </b> to set the default time-out given to an environment.</li>
|
||||
|
||||
<LI>
|
||||
<B>-T</B> to set the maximum time-out allowed for the server.</LI>
|
||||
<li>
|
||||
<b>-T</b> to set the maximum time-out allowed for the server.</li>
|
||||
|
||||
<LI>
|
||||
<B>-L</B> to log the execution of the server process to a specified file.</LI>
|
||||
<li>
|
||||
<b>-L</b> to log the execution of the server process to a specified file.</li>
|
||||
|
||||
<LI>
|
||||
<B>-v</B> to run in verbose mode.</LI>
|
||||
<li>
|
||||
<b>-v</b> to run in verbose mode.</li>
|
||||
|
||||
<LI>
|
||||
<B>-M</B> to specify the maximum number of outstanding child server
|
||||
<li>
|
||||
<b>-M</b> to specify the maximum number of outstanding child server
|
||||
processes/threads we can have at any given time. The default is 10.
|
||||
<B>[We
|
||||
are not yet doing multiple threads/processes.]</B></LI>
|
||||
</UL>
|
||||
<b>[We
|
||||
are not yet doing multiple threads/processes.]</b></li>
|
||||
</ul>
|
||||
|
||||
<H2>
|
||||
The Client Code</H2>
|
||||
<h2>
|
||||
The Client Code</h2>
|
||||
The client code contains all of the supported functions and methods used
|
||||
in this model. There are several methods in the <I>__db_env
|
||||
</I>and
|
||||
<I>__db</I>
|
||||
in this model. There are several methods in the <i>__db_env
|
||||
</i>and
|
||||
<i>__db</i>
|
||||
structures that currently do not apply, such as the callbacks. Those
|
||||
fields that are not applicable to the client model point to NULL to notify
|
||||
the user of their error. Some method functions remain unchanged,
|
||||
as well such as the error calls.
|
||||
<P>The client code contains each method function that goes along with the
|
||||
<A HREF="#Remote Procedure Calls">RPC
|
||||
calls</A> described elsewhere. The client library also contains its
|
||||
own version of <A HREF="../docs/api_c/env_create.html">db_env_create()</A>,
|
||||
<p>The client code contains each method function that goes along with the
|
||||
<a href="#Remote Procedure Calls">RPC
|
||||
calls</a> described elsewhere. The client library also contains its
|
||||
own version of <a href="../docs/api_c/env_create.html">db_env_create()</a>,
|
||||
which does not result in any messages going over to the server (since we
|
||||
do not yet know what server we are talking to). This function sets
|
||||
up the pointers to the correct client functions.
|
||||
<P>All of the method functions that handle the messaging have a basic flow
|
||||
<p>All of the method functions that handle the messaging have a basic flow
|
||||
similar to this:
|
||||
<UL>
|
||||
<LI>
|
||||
Local arg parsing that may be needed</LI>
|
||||
<ul>
|
||||
<li>
|
||||
Local arg parsing that may be needed</li>
|
||||
|
||||
<LI>
|
||||
<li>
|
||||
Marshalling the message header and the arguments we need to send to the
|
||||
server</LI>
|
||||
server</li>
|
||||
|
||||
<LI>
|
||||
Sending the message</LI>
|
||||
<li>
|
||||
Sending the message</li>
|
||||
|
||||
<LI>
|
||||
Receiving a reply</LI>
|
||||
<li>
|
||||
Receiving a reply</li>
|
||||
|
||||
<LI>
|
||||
Unmarshalling the reply</LI>
|
||||
<li>
|
||||
Unmarshalling the reply</li>
|
||||
|
||||
<LI>
|
||||
Local results processing that may be needed</LI>
|
||||
</UL>
|
||||
<li>
|
||||
Local results processing that may be needed</li>
|
||||
</ul>
|
||||
|
||||
<H2>
|
||||
Generated Code</H2>
|
||||
<h2>
|
||||
Generated Code</h2>
|
||||
Almost all of the code is generated from a source file describing the interface
|
||||
and an <I>awk</I> script. This awk script generates six (6)
|
||||
and an <i>awk</i> script. This awk script generates six (6)
|
||||
files for us. It also modifies one. The files are:
|
||||
<OL>
|
||||
<LI>
|
||||
Client file - The C source file created containing the client code.</LI>
|
||||
<ol>
|
||||
<li>
|
||||
Client file - The C source file created containing the client code.</li>
|
||||
|
||||
<LI>
|
||||
<li>
|
||||
Client template file - The C template source file created containing interfaces
|
||||
for handling client-local issues such as resource allocation, but with
|
||||
a consistent interface with the client code generated.</LI>
|
||||
a consistent interface with the client code generated.</li>
|
||||
|
||||
<LI>
|
||||
Server file - The C source file created containing the server code.</LI>
|
||||
<li>
|
||||
Server file - The C source file created containing the server code.</li>
|
||||
|
||||
<LI>
|
||||
<li>
|
||||
Server template file - The C template source file created containing interfaces
|
||||
for handling server-local issues such as resource allocation, calling into
|
||||
the DB library but with a consistent interface with the server code generated.</LI>
|
||||
the DB library but with a consistent interface with the server code generated.</li>
|
||||
|
||||
<LI>
|
||||
XDR file - The XDR message description file created.</LI>
|
||||
<li>
|
||||
XDR file - The XDR message description file created.</li>
|
||||
|
||||
<LI>
|
||||
<li>
|
||||
Server sed file - A sed script that contains commands to apply to the server
|
||||
procedure file (i.e. the real source file that the server template file
|
||||
becomes) so that minor interface changes can be consistently and easily
|
||||
applied to the real code.</LI>
|
||||
applied to the real code.</li>
|
||||
|
||||
<LI>
|
||||
<li>
|
||||
Server procedure file - This is the file that is modified by the sed script
|
||||
generated. It originated from the server template file.</LI>
|
||||
</OL>
|
||||
The awk script reads a source file, <I>db_server/rpc.src </I>that describes
|
||||
generated. It originated from the server template file.</li>
|
||||
</ol>
|
||||
The awk script reads a source file, <i>db_server/rpc.src </i>that describes
|
||||
each operation and what sorts of arguments it takes and what it returns
|
||||
from the server. The syntax of the source file describes the interface
|
||||
to that operation. There are four (4) parts to the syntax:
|
||||
<OL>
|
||||
<LI>
|
||||
<B>BEGIN</B> <B><I>function version# codetype</I></B> - begins a new functional
|
||||
interface for the given <B><I>function</I></B>. Each function has
|
||||
a <B><I>version number</I></B>, currently all of them are at version number
|
||||
one (1). The <B><I>code type</I></B> indicates to the awk script
|
||||
what kind of code to generate. The choices are:</LI>
|
||||
<ol>
|
||||
<li>
|
||||
<b>BEGIN</b> <b><i>function version# codetype</i></b> - begins a new functional
|
||||
interface for the given <b><i>function</i></b>. Each function has
|
||||
a <b><i>version number</i></b>, currently all of them are at version number
|
||||
one (1). The <b><i>code type</i></b> indicates to the awk script
|
||||
what kind of code to generate. The choices are:</li>
|
||||
|
||||
<UL>
|
||||
<LI>
|
||||
<B>CODE </B>- Generate all code, and return a status value. If specified,
|
||||
<ul>
|
||||
<li>
|
||||
<b>CODE </b>- Generate all code, and return a status value. If specified,
|
||||
the client code will simply return the status to the user upon completion
|
||||
of the RPC call.</LI>
|
||||
of the RPC call.</li>
|
||||
|
||||
<LI>
|
||||
<B>RETCODE </B>- Generate all code and call a return function in the client
|
||||
<li>
|
||||
<b>RETCODE </b>- Generate all code and call a return function in the client
|
||||
template file to deal with client issues or with other returned items.
|
||||
If specified, the client code generated will call a function of the form
|
||||
<I>__dbcl_<name>_ret()
|
||||
</I>where
|
||||
<i>__dbcl_<name>_ret()
|
||||
</i>where
|
||||
<name> is replaced with the function name given here. This function
|
||||
is placed in the template file because this indicates that something special
|
||||
must occur on return. The arguments to this function are the same
|
||||
as those for the client function, with the addition of the reply message
|
||||
structure.</LI>
|
||||
structure.</li>
|
||||
|
||||
<LI>
|
||||
<B>NOCLNTCODE - </B>Generate XDR and server code, but no corresponding
|
||||
<li>
|
||||
<b>NOCLNTCODE - </b>Generate XDR and server code, but no corresponding
|
||||
client code. (This is used for functions that are not named the same thing
|
||||
on both sides. The only use of this at the moment is db_env_create
|
||||
and db_create. The environment create call to the server is actually
|
||||
called from the <A HREF="../docs/api_c/env_set_server.html">DBENV->set_server()</A>
|
||||
called from the <a href="../docs/api_c/env_set_rpc_server.html">DBENV->set_rpc_server()</a>
|
||||
method. The db_create code exists elsewhere in the library and we
|
||||
modify that code for the client call.)</LI>
|
||||
</UL>
|
||||
modify that code for the client call.)</li>
|
||||
</ul>
|
||||
|
||||
<LI>
|
||||
<B>ARG <I>RPC-type C-type varname [list-type]</I></B>- each line of this
|
||||
describes an argument to the function. The argument is called <B><I>varname</I></B>.
|
||||
The <B><I>C-type</I></B> given is what it should look like in the C code
|
||||
generated, such as <B>DB *, u_int32_t, const char *</B>. The
|
||||
<B><I>RPC-type</I></B>
|
||||
<li>
|
||||
<b>ARG <i>RPC-type C-type varname [list-type]</i></b>- each line of this
|
||||
describes an argument to the function. The argument is called <b><i>varname</i></b>.
|
||||
The <b><i>C-type</i></b> given is what it should look like in the C code
|
||||
generated, such as <b>DB *, u_int32_t, const char *</b>. The
|
||||
<b><i>RPC-type</i></b>
|
||||
is an indication about how the RPC request message should be constructed.
|
||||
The RPC-types allowed are described below.</LI>
|
||||
The RPC-types allowed are described below.</li>
|
||||
|
||||
<LI>
|
||||
<B>RET <I>RPC-type C-type varname [list-type]</I></B>- each line of this
|
||||
<li>
|
||||
<b>RET <i>RPC-type C-type varname [list-type]</i></b>- each line of this
|
||||
describes what the server should return from this procedure call (in addition
|
||||
to a status, which is always returned and should not be specified).
|
||||
The argument is called <B><I>varname</I></B>. The <B><I>C-type</I></B>
|
||||
given is what it should look like in the C code generated, such as <B>DB
|
||||
*, u_int32_t, const char *</B>. The <B><I>RPC-type</I></B> is an
|
||||
The argument is called <b><i>varname</i></b>. The <b><i>C-type</i></b>
|
||||
given is what it should look like in the C code generated, such as <b>DB
|
||||
*, u_int32_t, const char *</b>. The <b><i>RPC-type</i></b> is an
|
||||
indication about how the RPC reply message should be constructed.
|
||||
The RPC-types are described below.</LI>
|
||||
The RPC-types are described below.</li>
|
||||
|
||||
<LI>
|
||||
<B>END </B>- End the description of this function. The result is
|
||||
that when the awk script encounters the <B>END</B> tag, it now has all
|
||||
the information it needs to construct the generated code for this function.</LI>
|
||||
</OL>
|
||||
The <B><I>RPC-type</I></B> must be one of the following:
|
||||
<UL>
|
||||
<LI>
|
||||
<B>IGNORE </B>- This argument is not passed to the server and should be
|
||||
ignored when constructing the XDR code. <B>Only allowed for an ARG
|
||||
specfication.</B></LI>
|
||||
<li>
|
||||
<b>END </b>- End the description of this function. The result is
|
||||
that when the awk script encounters the <b>END</b> tag, it now has all
|
||||
the information it needs to construct the generated code for this function.</li>
|
||||
</ol>
|
||||
The <b><i>RPC-type</i></b> must be one of the following:
|
||||
<ul>
|
||||
<li>
|
||||
<b>IGNORE </b>- This argument is not passed to the server and should be
|
||||
ignored when constructing the XDR code. <b>Only allowed for an ARG
|
||||
specfication.</b></li>
|
||||
|
||||
<LI>
|
||||
<B>STRING</B> - This argument is a string.</LI>
|
||||
<li>
|
||||
<b>STRING</b> - This argument is a string.</li>
|
||||
|
||||
<LI>
|
||||
<B>INT </B>- This argument is an integer of some sort.</LI>
|
||||
<li>
|
||||
<b>INT </b>- This argument is an integer of some sort.</li>
|
||||
|
||||
<LI>
|
||||
<B>DBT </B>- This argument is a DBT, resulting in its decomposition into
|
||||
the request message.</LI>
|
||||
<li>
|
||||
<b>DBT </b>- This argument is a DBT, resulting in its decomposition into
|
||||
the request message.</li>
|
||||
|
||||
<LI>
|
||||
<B>LIST</B> - This argument is an opaque list passed to the server (NULL-terminated).
|
||||
If an argument of this type is given, it must have a <B><I>list-type</I></B>
|
||||
specified that is one of:</LI>
|
||||
<li>
|
||||
<b>LIST</b> - This argument is an opaque list passed to the server (NULL-terminated).
|
||||
If an argument of this type is given, it must have a <b><i>list-type</i></b>
|
||||
specified that is one of:</li>
|
||||
|
||||
<UL>
|
||||
<LI>
|
||||
<B>STRING</B></LI>
|
||||
<ul>
|
||||
<li>
|
||||
<b>STRING</b></li>
|
||||
|
||||
<LI>
|
||||
<B>INT</B></LI>
|
||||
<li>
|
||||
<b>INT</b></li>
|
||||
|
||||
<LI>
|
||||
<B>ID</B>.</LI>
|
||||
</UL>
|
||||
<li>
|
||||
<b>ID</b>.</li>
|
||||
</ul>
|
||||
|
||||
<LI>
|
||||
<B>ID</B> - This argument is an identifier.</LI>
|
||||
</UL>
|
||||
<li>
|
||||
<b>ID</b> - This argument is an identifier.</li>
|
||||
</ul>
|
||||
So, for example, the source for the DB->join RPC call looks like:
|
||||
<PRE>BEGIN dbjoin 1 RETCODE
|
||||
<pre>BEGIN dbjoin 1 RETCODE
|
||||
ARG ID DB * dbp
|
||||
ARG LIST DBC ** curs ID
|
||||
ARG IGNORE DBC ** dbcpp
|
||||
ARG INT u_int32_t flags
|
||||
RET ID long dbcid
|
||||
END</PRE>
|
||||
END</pre>
|
||||
Our first line tells us we are writing the dbjoin function. It requires
|
||||
special code on the client so we indicate that with the RETCODE.
|
||||
This method takes four arguments. For the RPC request we need the
|
||||
|
|
@ -429,17 +429,17 @@ the cursor list, we ignore the argument to return the cursor handle to
|
|||
the user, and we pass along the flags. On the return, the reply contains
|
||||
a status, by default, and additionally, it contains the ID of the newly
|
||||
created cursor.
|
||||
<H2>
|
||||
Building and Installing</H2>
|
||||
<h2>
|
||||
Building and Installing</h2>
|
||||
I need to verify with Don Anderson, but I believe we should just build
|
||||
the server program, just like we do for db_stat, db_checkpoint, etc.
|
||||
Basically it can be treated as a utility program from the building and
|
||||
installation perspective.
|
||||
<P>As mentioned early on, in the section on <A HREF="#DB Modifications">DB
|
||||
Modifications</A>, we have a single library, but allowing the user to access
|
||||
the client portion by sending a flag to <A HREF="../docs/api_c/env_create.html">db_env_create()</A>.
|
||||
<p>As mentioned early on, in the section on <a href="#DB Modifications">DB
|
||||
Modifications</a>, we have a single library, but allowing the user to access
|
||||
the client portion by sending a flag to <a href="../docs/api_c/env_create.html">db_env_create()</a>.
|
||||
The Makefile is modified to include the new files.
|
||||
<P>Testing is performed in two ways. First I have a new example program,
|
||||
<p>Testing is performed in two ways. First I have a new example program,
|
||||
that should become part of the example directory. It is basically
|
||||
a merging of ex_access.c and ex_env.c. This example is adequate to
|
||||
test basic functionality, as it does just does database put/get calls and
|
||||
|
|
@ -449,5 +449,5 @@ I am going to modify the Tcl interface to accept the server information.
|
|||
Nothing else should need to change in Tcl. Then we can either write
|
||||
our own test modules or use a subset of the existing ones to test functionality
|
||||
on a regular basis.
|
||||
</BODY>
|
||||
</HTML>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue