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