1<?xml version="1.0" encoding="UTF-8" standalone="no"?> 2<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 3<html xmlns="http://www.w3.org/1999/xhtml"> 4 <head> 5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 6 <title>Chapter 1. Introduction</title> 7 <link rel="stylesheet" href="gettingStarted.css" type="text/css" /> 8 <meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /> 9 <link rel="home" href="index.html" title="Getting Started with Berkeley DB Transaction Processing" /> 10 <link rel="up" href="index.html" title="Getting Started with Berkeley DB Transaction Processing" /> 11 <link rel="previous" href="preface.html" title="Preface" /> 12 <link rel="next" href="recovery-intro.html" title="Recoverability" /> 13 </head> 14 <body> 15 <div class="navheader"> 16 <table width="100%" summary="Navigation header"> 17 <tr> 18 <th colspan="3" align="center">Chapter 1. Introduction</th> 19 </tr> 20 <tr> 21 <td width="20%" align="left"><a accesskey="p" href="preface.html">Prev</a> </td> 22 <th width="60%" align="center"> </th> 23 <td width="20%" align="right"> <a accesskey="n" href="recovery-intro.html">Next</a></td> 24 </tr> 25 </table> 26 <hr /> 27 </div> 28 <div class="chapter" lang="en" xml:lang="en"> 29 <div class="titlepage"> 30 <div> 31 <div> 32 <h2 class="title"><a id="introduction"></a>Chapter 1. Introduction</h2> 33 </div> 34 </div> 35 <div></div> 36 </div> 37 <div class="toc"> 38 <p> 39 <b>Table of Contents</b> 40 </p> 41 <dl> 42 <dt> 43 <span class="sect1"> 44 <a href="introduction.html#txnintro">Transaction Benefits</a> 45 </span> 46 </dt> 47 <dd> 48 <dl> 49 <dt> 50 <span class="sect2"> 51 <a href="introduction.html#sysfailure">A Note on System Failure</a> 52 </span> 53 </dt> 54 <dt> 55 <span class="sect2"> 56 <a href="introduction.html#apireq">Application Requirements</a> 57 </span> 58 </dt> 59 <dt> 60 <span class="sect2"> 61 <a href="introduction.html#multithread-intro">Multi-threaded 62 and Multi-process 63 Applications</a> 64 </span> 65 </dt> 66 </dl> 67 </dd> 68 <dt> 69 <span class="sect1"> 70 <a href="recovery-intro.html">Recoverability</a> 71 </span> 72 </dt> 73 <dt> 74 <span class="sect1"> 75 <a href="perftune-intro.html">Performance Tuning</a> 76 </span> 77 </dt> 78 </dl> 79 </div> 80 <p> 81 This book provides a thorough introduction and discussion on transactions as 82 used with Berkeley DB (DB). It begins by offering a general overview to 83 transactions, the guarantees they provide, and the general application 84 infrastructure required to obtain full transactional protection for your 85 data. 86 </p> 87 <p> 88 This book also provides detailed examples on how to write a 89 transactional application. Both single threaded and multi-threaded <span>(as well as multi-process 90 applications)</span> are discussed. A detailed description of various 91 backup and recovery strategies is included in this manual, as is a 92 discussion on performance considerations for your transactional application. 93 </p> 94 <p> 95 You should understand the concepts from the 96 <span> 97 <i class="citetitle">Getting Started with Berkeley DB</i> 98 </span> 99 100 101 guide before reading this book. 102 </p> 103 <div class="sect1" lang="en" xml:lang="en"> 104 <div class="titlepage"> 105 <div> 106 <div> 107 <h2 class="title" style="clear: both"><a id="txnintro"></a>Transaction Benefits</h2> 108 </div> 109 </div> 110 <div></div> 111 </div> 112 <p> 113 Transactions offer your application's data protection from 114 application or system failures. That is, DB transactions offer 115 your application full ACID support: 116 </p> 117 <div class="itemizedlist"> 118 <ul type="disc"> 119 <li> 120 <p> 121 <span class="bold"><b>A</b></span>tomicity 122 </p> 123 <p> 124 Multiple database operations are treated as a single unit of 125 work. Once committed, all write operations performed under 126 the protection of the transaction are saved to your databases. 127 Further, in the event that you abort a transaction, all write 128 operations performed during the transaction are discarded. 129 In this event, your database is left in the state it was in 130 before the transaction began, regardless of the number or 131 type of write operations you may have performed during the 132 course of the transaction. 133 </p> 134 <p> 135 Note that DB transactions can span one or more 136 database handles. 137 </p> 138 </li> 139 <li> 140 <p> 141 <span class="bold"><b>C</b></span>onsistency 142 </p> 143 <p> 144 Your databases will never see a partially completed 145 transaction. This is true even if your application fails while there are 146 in-progress transactions. If the application or system fails, 147 then either all of the database changes appear when the 148 application next runs, or none of them appear. 149 </p> 150 <p> 151 In other words, whatever consistency requirements your application has will never be violated by DB. 152 If, for example, your application requires every record to include an employee ID, and your 153 code faithfully adds that ID to its database records, then DB will never 154 violate that consistency requirement. The ID will remain in the database records until such a time as your 155 application chooses to delete it. 156 </p> 157 </li> 158 <li> 159 <p> 160 <span class="bold"><b>I</b></span>solation 161 </p> 162 <p> 163 While a transaction is in progress, your databases will appear 164 to the transaction as if there are no other operations 165 occurring outside of the transaction. That is, operations 166 wrapped inside a transaction will always have a clean and 167 consistent view of your databases. They never have to see 168 updates currently in progress under the protection of another transaction. 169 Note, however, that isolation guarantees can be 170 171 relaxed from the default setting. See 172 <a href="isolation.html">Isolation</a> 173 for more information. 174 </p> 175 </li> 176 <li> 177 <p> 178 <span class="bold"><b>D</b></span>urability 179 </p> 180 <p> 181 Once committed to your databases, your modifications will 182 persist even in the event of an application or system failure. 183 Note that like isolation, your durability guarantee can be 184 relaxed. See <a href="usingtxns.html#nodurabletxn">Non-Durable Transactions</a> 185 for more information. 186 </p> 187 </li> 188 </ul> 189 </div> 190 <div class="sect2" lang="en" xml:lang="en"> 191 <div class="titlepage"> 192 <div> 193 <div> 194 <h3 class="title"><a id="sysfailure"></a>A Note on System Failure</h3> 195 </div> 196 </div> 197 <div></div> 198 </div> 199 <p> 200 From time to time this manual mentions that transactions protect your data against 'system or application 201 failure.' This is 202 true up to a certain extent. However, not all failures are created equal and no data protection 203 mechanism can protect you against every conceivable way a computing system can find to die. 204 </p> 205 <p> 206 Generally, when this book talks about protection against failures, it means that 207 transactions offer protection against 208 the likeliest culprits for system and application crashes. So long as your data modifications have been 209 committed to disk, those modifications should persist even if your application or OS subsequently fails. 210 And, even if the application or OS fails in the middle of a transaction commit (or abort), the data on disk 211 should be either in a consistent state, or there should be enough data available to bring 212 your databases into a consistent state (via a recovery procedure, for example). You may, however, 213 lose whatever data you were committing at the 214 time of the failure, but your databases will be otherwise unaffected. 215 </p> 216 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> 217 <h3 class="title">Note</h3> 218 <p> 219 Be aware that many disks have a disk write cache and on 220 some systems it is enabled by default. This means that 221 a transaction can have committed, and to your 222 application the data may appear to reside on disk, but 223 the data may in fact reside only in the write cache at 224 that time. This means that if the disk write cache is 225 enabled and there is no battery backup for it, data can 226 be lost after an OS crash even when maximum durability 227 mode is in use. For maximum durability, disable the 228 disk write cache or use a disk write cache with a 229 battery backup. 230 </p> 231 </div> 232 <p> 233 Of course, if your <span class="emphasis"><em>disk</em></span> fails, then the transactional benefits described in this book 234 are only as good as the backups you have taken. 235 236 237 <span> 238 By spreading your data and log files across separate disks, 239 you can minimize the risk of data loss due to a disk failure, but even in this case it is possible to 240 conjure a scenario where even this protection is insufficient (a fire in the machine room, for example) and 241 you must go to your backups for protection. 242 </span> 243 </p> 244 <p> 245 Finally, by following the programming examples shown in this book, you can write your code so as to protect 246 your data in the event that your code crashes. However, no programming API can protect you against logic 247 failures in your own code; transactions cannot protect you from simply writing the wrong thing to your 248 databases. 249 </p> 250 </div> 251 <div class="sect2" lang="en" xml:lang="en"> 252 <div class="titlepage"> 253 <div> 254 <div> 255 <h3 class="title"><a id="apireq"></a>Application Requirements</h3> 256 </div> 257 </div> 258 <div></div> 259 </div> 260 <p> 261 In order to use transactions, your application has certain 262 requirements beyond what is required of non-transactional protected 263 applications. They are: 264 </p> 265 <div class="itemizedlist"> 266 <ul type="disc"> 267 <li> 268 <p> 269 Environments. 270 </p> 271 <p> 272 Environments are optional for non-transactional 273 applications, but they are required for transactional 274 applications. 275 </p> 276 <p> 277 Environments are optional for non-transactional 278 applications that use the base API, but they are required for transactional 279 applications. (Of course, applications that use the 280 DPL always require the DPL.) 281 </p> 282 <p> 283 Environment usage is described in detail in 284 <a href="usingtxns.html">Transaction Basics</a>. 285 </p> 286 </li> 287 <li> 288 <p> 289 Transaction subsystem. 290 </p> 291 <p> 292 In order to use transactions, you must explicitly 293 enable the transactional subsystem for your 294 application, and this must be done at the time that 295 your environment is first created. 296 </p> 297 </li> 298 <li> 299 <p> 300 Logging subsystem. 301 </p> 302 <p> 303 The logging subsystem is required for recovery purposes, but 304 its usage also means your application may require a 305 little more administrative effort than it does when logging 306 is not in use. See <a href="filemanagement.html">Managing DB Files</a> for more information. 307 </p> 308 </li> 309 <li> 310 <p> 311 <span>DB_TXN</span> 312 313 314 315 handles. 316 </p> 317 <p> 318 In order to obtain the atomicity guarantee offered by 319 the transactional subsystem (that is, combine multiple 320 operations in a single unit of work), your application must use 321 transaction handles. These handles are obtained from your 322 <span>DB_ENV</span> 323 324 325 326 objects. They should normally be short-lived, and their usage is 327 reasonably simple. To complete a transaction and save 328 the work it performed, you 329 call its <tt class="methodname">commit()</tt> method. To 330 complete a transaction and discard its work, you call its 331 <tt class="methodname">abort()</tt> method. 332 </p> 333 <p> 334 In addition, it is possible to use auto commit if you want 335 to transactional protect a single write operation. Auto 336 commit allows a transaction to be used without 337 obtaining an explicit transaction handle. See 338 <a href="autocommit.html">Auto Commit</a> 339 for information on how to use auto commit. 340 </p> 341 </li> 342 <li> 343 <p> 344 <span>Database</span> 345 346 open requirements. 347 </p> 348 <p> 349 350 <span>In addition to using 351 environments and initializing the 352 correct subsystems, your</span> 353 354 application must transaction protect the database 355 356 opens<span>, 357 and any secondary index associations,</span> 358 359 if subsequent operations on the databases are to be transaction 360 protected. The database open and secondary index 361 association are commonly transaction protected using 362 auto commit. 363 </p> 364 </li> 365 <li> 366 <p> 367 Deadlock detection. 368 </p> 369 <p> 370 Typically transactional applications use multiple 371 threads of control when accessing the database. Any 372 time multiple threads are used on a single resource, 373 the potential for lock contention arises. In turn, lock 374 contention can lead to deadlocks. See 375 <a href="blocking_deadlocks.html">Locks, Blocks, and Deadlocks</a> 376 for more information. 377 </p> 378 <p> 379 Therefore, transactional applications must frequently 380 include code for detecting and responding to deadlocks. 381 Note that this requirement is not 382 <span class="emphasis"><em>specific</em></span> to transactions 383 – you can certainly write concurrent 384 non-transactional DB applications. Further, not 385 every transactional application uses concurrency and 386 so not every transactional application must 387 manage deadlocks. Still, deadlock management is so 388 frequently a characteristic of transactional 389 applications that we discuss it in this 390 book. See <a href="txnconcurrency.html">Concurrency</a> 391 for more information. 392 </p> 393 </li> 394 </ul> 395 </div> 396 </div> 397 <div class="sect2" lang="en" xml:lang="en"> 398 <div class="titlepage"> 399 <div> 400 <div> 401 <h3 class="title"><a id="multithread-intro"></a>Multi-threaded 402 <span>and Multi-process</span> 403 Applications</h3> 404 </div> 405 </div> 406 <div></div> 407 </div> 408 <p> 409 DB is designed to support multi-threaded <span>and 410 multi-process</span> applications, but their usage means 411 you must pay careful attention to issues of concurrency. 412 Transactions help your application's concurrency by providing various levels of 413 isolation for your threads of control. In addition, DB 414 provides mechanisms that allow you to detect and respond to 415 deadlocks (but strictly speaking, this is not limited to just 416 transactional applications). 417 </p> 418 <p> 419 <span class="emphasis"><em>Isolation</em></span> means that database modifications made by 420 one transaction will not normally be seen by readers from another 421 transaction until the first commits its changes. Different threads 422 use different transaction handles, so 423 this mechanism is normally used to provide isolation between 424 database operations performed by different threads. 425 </p> 426 <p> 427 Note that DB supports different isolation levels. For example, 428 you can configure your application to see uncommitted reads, which means 429 that one transaction can see data that has been modified but not yet 430 committed by another transaction. Doing this might mean your 431 transaction reads data "dirtied" by another transaction, 432 but which subsequently might change before that 433 other transaction commits its changes. 434 On the other hand, lowering your isolation 435 requirements means that your application can experience 436 improved throughput due to reduced lock contention. 437 </p> 438 <p> 439 For more information on concurrency, on managing isolation 440 levels, and on deadlock detection, see <a href="txnconcurrency.html">Concurrency</a>. 441 </p> 442 </div> 443 </div> 444 </div> 445 <div class="navfooter"> 446 <hr /> 447 <table width="100%" summary="Navigation footer"> 448 <tr> 449 <td width="40%" align="left"><a accesskey="p" href="preface.html">Prev</a> </td> 450 <td width="20%" align="center"> 451 <a accesskey="u" href="index.html">Up</a> 452 </td> 453 <td width="40%" align="right"> <a accesskey="n" href="recovery-intro.html">Next</a></td> 454 </tr> 455 <tr> 456 <td width="40%" align="left" valign="top">Preface </td> 457 <td width="20%" align="center"> 458 <a accesskey="h" href="index.html">Home</a> 459 </td> 460 <td width="40%" align="right" valign="top"> Recoverability</td> 461 </tr> 462 </table> 463 </div> 464 </body> 465</html> 466