ug_ch7.htm
来自「db.* (pronounced dee-be star) is an adva」· HTM 代码 · 共 1,725 行 · 第 1/5 页
HTM
1,725 行
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//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.* User's Guide Chapter 7</title></head><body><h1><a name="Control" id="Control"></a>Chapter 7<br>Multi-User Database Control</h1><h2><a name="Introduction" id="Introduction"></a>7.1Introduction</h2><p><font size="2">In the example below, two users are attempting toupdate a record from the database at about the same time. The leftcolumn gives a relative time and the other columns identify theactions that occur for the respective user at each time.</font></p><p align="center"><b>Table 7-1. Two Users Updating a Record</b></p><table cellspacing="0" border="0" cellpadding="7" width="542"><tr><td width="19%" valign="top"><p><b><font size="2">Time</font></b></p></td><td width="41%" valign="top"><p><b><font size="2">User 1</font></b></p></td><td width="41%" valign="top"><p><b><font size="2">User 2</font></b></p></td></tr><tr><td width="19%" valign="top"><p><font size="2">1</font></p></td><td width="41%" valign="top"><p><font size="2">Read record</font></p></td><td width="41%" valign="top"> </td></tr><tr><td width="19%" valign="top"><p><font size="2">2</font></p></td><td width="41%" valign="top"> </td><td width="41%" valign="top"><p><font size="2">Read record</font></p></td></tr><tr><td width="19%" valign="top"><p><font size="2">3</font></p></td><td width="41%" valign="top"><p><font size="2">Modify record</font></p></td><td width="41%" valign="top"> </td></tr><tr><td width="19%" valign="top"><p><font size="2">4</font></p></td><td width="41%" valign="top"> </td><td width="41%" valign="top"><p><font size="2">Modify record</font></p></td></tr><tr><td width="19%" valign="top"><p><font size="2">5</font></p></td><td width="41%" valign="top"><p><font size="2">Write record</font></p></td><td width="41%" valign="top"> </td></tr><tr><td width="19%" valign="top"><p><font size="2">6</font></p></td><td width="41%" valign="top"> </td><td width="41%" valign="top"><p><font size="2">Write record</font></p></td></tr></table><font size="2"><br><br></font><p><font size="2">At Time 1, User 1 reads the record from thedatabase. At Time 2, User 2 reads the record. Both users thenmodify and write the record back to the database. But User 2's copyof the record does not have User 1's changes (they were made afterUser 2 read the record). Thus, when User 2's record is written tothe database, User 1's changes are lost. If User 2 had not read therecord until after Time 5, the changes from User 1 would not havebeen lost. But without any control, there is no way to guaranteethat User 2 will put off reading until User 1's updates arecompleted.</font></p><p>The solution is to provide a mechanism whereby updates to shareddata are synchronized, so that only one user can be updating theshared data at a time. The mechanism usually is some form of alock, which is used to serialize updates to data shared amongmultiple users. A lock must be applied before shared data isupdated, so that other users cannot update the locked data. Thus,through use of a lock, the above example would proceed as shown inthe following table:</p><p align="center"><b>Table 7-2. Two Users Updating a Record, UsingLocks</b></p><table cellspacing="0" border="0" cellpadding="7" width="542"><tr><td width="15%" valign="top"><p><b><font size="2">Time</font></b></p></td><td width="43%" valign="top"><p><b><font size="2">User 1</font></b></p></td><td width="43%" valign="top"><p><b><font size="2">User 2</font></b></p></td></tr><tr><td width="15%" valign="top"><p><font size="2">1</font></p></td><td width="43%" valign="top"><p><font size="2">Request record lock</font></p></td><td width="43%" valign="top"> </td></tr><tr><td width="15%" valign="top"><p><font size="2">2</font></p></td><td width="43%" valign="top"><p><font size="2">Lock granted</font></p></td><td width="43%" valign="top"><p><font size="2">Request record lock</font></p></td></tr><tr><td width="15%" valign="top"><p><font size="2">3</font></p></td><td width="43%" valign="top"><p><font size="2">Read record</font></p></td><td width="43%" valign="top"> </td></tr><tr><td width="15%" valign="top"><p><font size="2">4</font></p></td><td width="43%" valign="top"><p><font size="2">Modify record</font></p></td><td width="43%" valign="top"> </td></tr><tr><td width="15%" valign="top"><p><font size="2">5</font></p></td><td width="43%" valign="top"><p><font size="2">Write record</font></p></td><td width="43%" valign="top"> </td></tr><tr><td width="15%" valign="top"><p><font size="2">6</font></p></td><td width="43%" valign="top"><p><font size="2">Free lock</font></p></td><td width="43%" valign="top"><p><font size="2">Lock granted</font></p></td></tr><tr><td width="15%" valign="top"><p><font size="2">7</font></p></td><td width="43%" valign="top"> </td><td width="43%" valign="top"><p><font size="2">Read record</font></p></td></tr><tr><td width="15%" valign="top"><p><font size="2">8</font></p></td><td width="43%" valign="top"> </td><td width="43%" valign="top"><p><font size="2">Modify record</font></p></td></tr><tr><td width="15%" valign="top"><p><font size="2">9</font></p></td><td width="43%" valign="top"> </td><td width="43%" valign="top"><p><font size="2">Write record</font></p></td></tr><tr><td width="15%" valign="top"><p><font size="2">10</font></p></td><td width="43%" valign="top"> </td><td width="43%" valign="top"><p><font size="2">Free lock</font></p></td></tr></table><p><font size="2">Once User 1's lock request is granted at Time 2,User 2 will wait for the record to be unlocked before continuing.When User 1 has completed the update, the lock is freed at Time 6.User 2 is then granted the lock, and the record (which now includesUser 1's changes) is read and then updated with User 2'schanges.</font></p><p>As the above example illustrates, the key issue in multi-userdatabase applications is data integrity, ensuring that no data islost and that the data is logically consistent (that is, theinterdata relationships that should exist do exist). Data integrityis supported in <b><i>db.*</i></b> through three interrelatedfacilities:</p><ul><li>File and record locking</li><li>Transaction processing</li><li>Transaction logging and recovery</li></ul><p>File locking and record locking are used, as in the example, toprevent loss of data by synchronizing access to shared files andrecords so that only one user at a time can update them.</p><p>Multi-user database application programming is a difficult task,which should be approached with careful planning and design. Theproblems that can occur in multi-user programs are often verydifficult to resolve. The capabilities provided in<b><i>db.*</i></b> are sufficient for you to ensure both dataintegrity and good performance. The remainder of this chapterexplains the <b><i>db.*</i></b> implementation of thesecapabilities, including guidelines for their effective use.</p><h2><a name="Environment" id="Environment"></a>7.2 OperationalEnvironment</h2><p><font size="2">The <b><i>db.*</i></b> multi-user operationalenvironment is depicted in Figure 7-1.</font></p><p align="center"><b><img alt="dbstar_7-1.gif - 7067 Bytes" border="0" height="301" src="dbstar_7-1.gif" width="397"></b></p><p align="center">Fig. 7-1. Multi-User Operational Environment</p><p>Each process executes its own copy of the database program. On amulti-user UNIX/Linux system, the program executes as a separateprocess. Each process will be referred to as a user. Each user musthave a unique user identifier. The user id can be specified eitherthrough the DBUSERID environment variable or through a call tofunction <b>d_dbuserid</b> prior to the <b>d_open</b> call. The<b>db.star.ini</b> file cannot be used to specify the user id.</p><p>If transaction logging is to be used, each user will have aunique transaction log file. By default, the name of the log fileis <b>userid.log</b>. The log file's name and location can bespecified through either the DBLOG environment variable or the<b>db.star.ini</b> file or function <b>d_dblog</b>, which also mustbe called before the database is opened. The transaction logcontains the database changes made by the user within atransaction, and is used to support recovery.</p><p>Management of the <b><i>db.*</i></b> locks, and control ofautomatic recovery, is performed by the <b><i>db.*</i></b> lockmanager. Each process sends lock requests to the lock manager,which queues the requests on a "first come, first served" basis.The process will wait for the lock manager to send a reply eithergranting or denying the request. Locks are denied when the lockrequest has waited on the queue for a period longer than thetimeout value specified by the requesting process. The lock manageris a program that can be executed from any node on a network or asa background task on a stand-alone machine. See the<b><i>db.*</i></b> <i>Multi-User Guide</i> for a completedescription of the lock manager.</p><p>A database-family transaction activity file (TAF) is used by the<b><i>db.*</i></b> runtime to control database recovery in theevent the lock manager goes down. This file is named<b>db.star.taf</b> by default, but can be named or located througheither environment variable DBTAF or function <b>d_dbtaf</b>, orthe <b>db.star.ini</b> file, which must be called before<b>d_open</b>.</p><p>Each database family must use only one TAF so that automaticrecovery is done correctly. Also, all log files for the databasefamily (TAF) must be located in the same physical directory. Theapplication must enforce these rules through the consistent use ofthe environment variables, their corresponding <b>d_</b> functions,and the <b>db.star.ini</b> file.</p><p>Multi-user database programs must open the database in sharedaccess mode. This is done by passing an open type of "s" tofunction <b>d_open</b>. For example, to open the <b>tims</b>database for multi-user access, issue the following call:</p><pre><font color="#0000FF">if (d_open("tims", "s", task) == S_UNAVAIL){ printf("database unavailable\n"); exit(1);}</font></pre><p><font size="2">Status code S_UNAVAIL is returned when some otherdatabase program has opened the <b>tims</b> database in exclusiveaccess mode.</font></p><h2><a name="Locking" id="Locking"></a>7.3 File Locking</h2><h3><a name="LockingIntroduction" id="LockingIntroduction"></a>7.3.1 Introduction</h3><p><font size="2">The principal locking mechanism provided by<b><i>db.*</i></b> is the file lock. An advisory record lockingcapability, which is used in conjunction with file locking, is alsoprovided and is described in section 7.5, "Advisory Record Locks."Although file locking is often regarded as an inferior multi-userlocking mechanism, in the <b><i>db.*</i></b> environment it can beused very effectively without sacrificing performance. In fact,well-performing multi-user applications can and have been writtenusing only file locking.</font></p><p>Much of the file locking functionality provided in<b><i>db.*</i></b> has been developed to optimize multi-userperformance. In addition, section 7.6, "Program DesignConsiderations," gives some general program design guidelines tohelp you effectively use the <b><i>db.*</i></b> capabilities. Table7-3 lists the file locking functions.</p><p align="center"><b>Table 7-3. File Locking Functions</b></p><table cellspacing="0" border="0" cellpadding="7" width="542"><tr><td width="40%" valign="top"><p><b><font size="2">Function</font></b></p></td><td width="60%" valign="top"><p><b><font size="2">Definition</font></b></p></td></tr><tr><td width="40%" valign="top"><p><font size="2">d_reclock(<i>REC</i>, <i>type, task,dbn</i>)</font></p></td><td width="60%" valign="top"><p><font size="2">Lock data and key files associated with recordtype</font></p></td></tr><tr><td width="40%" valign="top">⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?