📄 mu_ch1.htm
字号:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN"><html><head><meta name="generator" content="HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org"><meta http-equiv="content-type" content="text/html; charset=us-ascii"><meta name="Generator" content="Microsoft Word 97"><title>db.* Multi-User Guide Chapter 1</title></head><body><h1><a name="Introduction"></a>Chapter 1<br>Introduction</h1><h2><a name="Overview"></a>1.1 Overview</h2><p><font size="2">Welcome to the <b><i>db.*</i></b>system.</font></p><p>This manual contains the information you need to build yourapplication in multi-user mode. It explains how to get the lockmanager utility up and running, plus how to use <b><i>db.*</i></b>on a variety of platforms. The <b><i>db*</i> User's Guide</b> alsocontains information on multi-user operation. Refer to Chapter 7,"Multi-User Database Control," of the <i>User's Guide</i> forinformation on file locking, timestamping, concurrency, andconsiderations on program design. Be sure to consult the<b>readme.txt</b> file included in your product package for recentchanges and information not included in the manuals.</p><p>This <i>Multi-User Guide</i> is organized as follows:</p><p>Chapter 1, "Introduction," describes the theory of operation ofa lock manager, and why a lock manager is necessary for allmulti-user, shared database applications.</p><p>Chapter 2, "Lock Manager Operation," describes how to use thelock manager and how to configure the runtime library formulti-user operation.</p><p>Chapter 3, "Platform Dependencies," provides informationconcerning the use of <b><i>db.*</i></b> with a variety ofdifferent operating systems and network protocols.</p><p>Chapter 4, "Lock Manager Reference," provides the referencematerial for the lock manager, including descriptions of relatedutilities and function calls.</p><h2><a name="Theory"></a>1.2 Lock Manager Theory</h2><p><font size="2">The most important feature of a multi-userdatabase is protecting data integrity when many applications arereading from and writing to the same set of files. In this chapterwe will examine the components that provide safe multi-user access,how the components communicate, and how the components candependably work with your data.</font></p><h3><a name="Components"></a>1.2.1<i>db.*</i> Multi-UserComponents</h3><p><font size="2">With <b><i>db.*</i></b>, a lock manager is usedto manage file locks and automatically recover failed transactions.The lock manager itself never reads or writes database, LOG, or TAFfiles. Normally the lock manager is a separate program that runs ona single machine on your network.</font></p><p>Applications based on <b><i>db.*</i></b> communicate with thelock manager to request permission to access a database file. Thecode for this communication is built into the <b><i>db.*</i></b>runtime library, and uses the facilities of the hostingenvironment.</p><p>The database, which the applications access, can be hostedanywhere that provides file system access to the application. Thisis not necessarily on the same machine as any application or thelock manager.</p><p>The applications will also create files (TAF, LOG, and DBL) thatare by-products of the locking process.</p><h3><a name="Communication"></a>1.2.2 EstablishingCommunication</h3><p><font size="2">First, the <b><i>db.*</i></b> lock manager mustbe started so that applications can use it.</font></p><p>The applications connect to the lock manager to open theirdatabases. When the <b>d_open</b> function successfully returns,the runtime will have already created a persistent connection tothe running lock manager that will be maintained until all theuser's databases have been closed. Associated with each connectionis a user identifier of not more than 15 characters, set through<b>d_dbuserid</b> or through the environment variable DBUSERID. Oneconnection and one unique userid exist per DB_TASK.</p><p>Applications use this connection to submit requests to the lockmanager. Requests can include file locks and unlocks, transactioncommits, status requests, and the terminal close that will end theconnection. The lock manager never initiates contact with anapplication; all packets from the lock manager are responses toapplication requests.</p><p>Network problems, crashed applications, or an unexpectedlyterminated lock manager can abruptly interrupt this orderlyexchange of data. If the lock manager loses contact with anapplication, it will clear out the user's data and prepare forrecovery if necessary. If an application loses contact with thelock manager, it will receive an error code of S_LMCERROR inresponse to a call to the runtime library.</p><h3><a name="Using"></a>1.2.3 Using The Database</h3><p><font size="2">Most requests are lock requests, where theapplication asks for read or write locks on files in the openeddatabases. No locks are active on a just-openeddatabase.</font></p><p>The life cycle of a lock begins with the application sending alock request. If it cannot be granted immediately, the request isqueued with all other lock requests. The oldest pending requestthat can be granted is always granted first. The lock managerrejects a lock request only if it cannot be granted before theuser's specified timeout elapses.</p><p>All locks are file locks. Any number of users can haveconcurrent read locks. If any read locks are outstanding, writelocks on the same file will be queued to be granted as soon aspossible. A write lock prevents any other lock from being grantedon the same file.</p><h3><a name="Transactions"></a>1.2.4 Transactions</h3><p><font size="2">The lock manager is not involved in a transactionuntil the application calls <b>d_trend</b>. After writing alldatabase changes to the LOG file and before writing to the databasefiles, the runtime sends a "transaction commit begin" message(which includes the LOG filename) to the lock manager. The lockmanager flags the user as "in the process of committing atransaction" and then stores the LOG filename.</font></p><p>When the runtime receives the lock manager's reply, it is freeto begin writing to the database. The changes are migrated from theLOG file to the database files. When all writing is complete, theruntime sends a "transaction commit end" message to the lockmanager. The lock manager unflags the user. This completes the lifecycle of a successful transaction.</p><p>If communication is disrupted before the "transaction commitend" message is received, the lock manager will know that atransaction was in progress and prepare for auto-recovery. Forpreparation, the lock manager tells the next application sendingany database open or lock request packet to perform a recoverybased on the LOG file written by the lost application. Theautomatic recovery process is described in section 6.5, "DatabaseRecovery," of the <b><i>db.*</i></b> <i>User's Guide</i>.</p><h3><a name="SystemFiles"></a>1.2.5<i>db.*</i> System Files</h3><p><font size="2">The LOG file contains all the data written to adatabase in a single transaction, and provides data integrity inthe case of an application crash during writes to the databasefiles. The LOG file is written by the runtime, and must be storedin a location visible to all applications using the same lockmanager. All LOG files must be stored in the same directory. TheLOG directory is specified using <b>d_dblog</b>,<b>db.star.ini</b>, or the environment variable DBLOG. One LOG fileexists per user (per DB_TASK) and cannot be shared. The name of theLOG file (without extension or path) is the userid truncated to 8characters.</font></p><p><font size="2">The TAF file has two purposes: 1) it ensures thatall users of a database use the same lock manager, and 2) itprovides pointers to LOG files for outstanding transactions in theevent of a simultaneous lock manager and application crash. Eachdatabase has only one TAF file, but a single TAF file may servemore than one database.</font></p><p><font size="2">All users of a database must use the same TAFpath, which is specified using <b>d_dbtaf</b>, <b>db.star.ini</b>,or the environment variable DBTAF. If the TAF file does not exist,the <b><i>db.*</i></b> runtime creates it when you call<b>d_open</b>, writing to the TAF file the lock manager name (asset through <b>d_lockmgr</b>, etc.) and type (for example,LMC_TCP). If the current lock manager name and type do not matchthose in an existing TAF file, <b>d_open</b> will fail and returnS_TAFSYNC. Deleting the TAF file eliminates this error. However, ifthe database is corrupt and needs recovery, deleting the TAF filewill prevent the recovery from occurring and you will be left witha corrupted database.</font></p><p><font size="2">Unless the MULTITAF option is enabled,<b><i>db.*</i></b> will only create one TAF file, which will beshared by all users. <b><i>db.*</i></b> uses operating systemspecific functions to lock the TAF file, to prevent multiple usersfrom writing to it simultaneously. However, on some networkedsystems these locking functions may be slow. <b><i>db.*</i></b>therefore provides the MULTITAF option, which causes a TAF file tobe created for each user, avoiding the need for locking. The TAFfiles must all be located same directory, otherwise<b><i>db.*</i></b> s auto-recovery mechanism will not workcorrectly, in the event of system failure during a transaction. Thedirectory is specified through <b>d_dbtaf</b>, <b>db.star.ini</b>,or the environment variable DBTAF; trailing characters after thelast directory character will be ignored.</font></p><p><font size="2">The DBL file is created by the General lockmanager. This lock manager involves cooperation between runtimesonly, and uses no lock manager process. All information aboutfiles, locks, and users is stored in the DBL file instead of in thememory of a lock manager program. Each database has only one DBLfile, but a single DBL file may serve more than onedatabase.</font></p><p><a href="MU_Ch2.htm">Next Page</a></p></body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -