<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>Chapter 1. Introduction</title> <link rel="stylesheet" href="gettingStarted.css" type="text/css" /> <meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /> <link rel="home" href="index.html" title="Getting Started with Berkeley DB Transaction Processing" /> <link rel="up" href="index.html" title="Getting Started with Berkeley DB Transaction Processing" /> <link rel="previous" href="preface.html" title="Preface" /> <link rel="next" href="recovery-intro.html" title="Recoverability" /> </head> <body> <div class="navheader"> <table width="100%" summary="Navigation header"> <tr> <th colspan="3" align="center">Chapter 1. Introduction</th> </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="preface.html">Prev</a> </td> <th width="60%" align="center"> </th> <td width="20%" align="right"> <a accesskey="n" href="recovery-intro.html">Next</a></td> </tr> </table> <hr /> </div> <div class="chapter" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> <h2 class="title"><a id="introduction"></a>Chapter 1. Introduction</h2> </div> </div> <div></div> </div> <div class="toc"> <p> <b>Table of Contents</b> </p> <dl> <dt> <span class="sect1"> <a href="introduction.html#txnintro">Transaction Benefits</a> </span> </dt> <dd> <dl> <dt> <span class="sect2"> <a href="introduction.html#sysfailure">A Note on System Failure</a> </span> </dt> <dt> <span class="sect2"> <a href="introduction.html#apireq">Application Requirements</a> </span> </dt> <dt> <span class="sect2"> <a href="introduction.html#multithread-intro">Multi-threaded and Multi-process Applications</a> </span> </dt> </dl> </dd> <dt> <span class="sect1"> <a href="recovery-intro.html">Recoverability</a> </span> </dt> <dt> <span class="sect1"> <a href="perftune-intro.html">Performance Tuning</a> </span> </dt> </dl> </div> <p> This book provides a thorough introduction and discussion on transactions as used with Berkeley DB (DB). It begins by offering a general overview to transactions, the guarantees they provide, and the general application infrastructure required to obtain full transactional protection for your data. </p> <p> This book also provides detailed examples on how to write a transactional application. Both single threaded and multi-threaded <span>(as well as multi-process applications)</span> are discussed. A detailed description of various backup and recovery strategies is included in this manual, as is a discussion on performance considerations for your transactional application. </p> <p> You should understand the concepts from the <span> <i class="citetitle">Getting Started with Berkeley DB</i> </span> guide before reading this book. </p> <div class="sect1" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> <h2 class="title" style="clear: both"><a id="txnintro"></a>Transaction Benefits</h2> </div> </div> <div></div> </div> <p> Transactions offer your application's data protection from application or system failures. That is, DB transactions offer your application full ACID support: </p> <div class="itemizedlist"> <ul type="disc"> <li> <p> <span class="bold"><b>A</b></span>tomicity </p> <p> Multiple database operations are treated as a single unit of work. Once committed, all write operations performed under the protection of the transaction are saved to your databases. Further, in the event that you abort a transaction, all write operations performed during the transaction are discarded. In this event, your database is left in the state it was in before the transaction began, regardless of the number or type of write operations you may have performed during the course of the transaction. </p> <p> Note that DB transactions can span one or more database handles. </p> </li> <li> <p> <span class="bold"><b>C</b></span>onsistency </p> <p> Your databases will never see a partially completed transaction. This is true even if your application fails while there are in-progress transactions. If the application or system fails, then either all of the database changes appear when the application next runs, or none of them appear. </p> <p> In other words, whatever consistency requirements your application has will never be violated by DB. If, for example, your application requires every record to include an employee ID, and your code faithfully adds that ID to its database records, then DB will never violate that consistency requirement. The ID will remain in the database records until such a time as your application chooses to delete it. </p> </li> <li> <p> <span class="bold"><b>I</b></span>solation </p> <p> While a transaction is in progress, your databases will appear to the transaction as if there are no other operations occurring outside of the transaction. That is, operations wrapped inside a transaction will always have a clean and consistent view of your databases. They never have to see updates currently in progress under the protection of another transaction. Note, however, that isolation guarantees can be relaxed from the default setting. See <a href="isolation.html">Isolation</a> for more information. </p> </li> <li> <p> <span class="bold"><b>D</b></span>urability </p> <p> Once committed to your databases, your modifications will persist even in the event of an application or system failure. Note that like isolation, your durability guarantee can be relaxed. See <a href="usingtxns.html#nodurabletxn">Non-Durable Transactions</a> for more information. </p> </li> </ul> </div> <div class="sect2" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> <h3 class="title"><a id="sysfailure"></a>A Note on System Failure</h3> </div> </div> <div></div> </div> <p> From time to time this manual mentions that transactions protect your data against 'system or application failure.' This is true up to a certain extent. However, not all failures are created equal and no data protection mechanism can protect you against every conceivable way a computing system can find to die. </p> <p> Generally, when this book talks about protection against failures, it means that transactions offer protection against the likeliest culprits for system and application crashes. So long as your data modifications have been committed to disk, those modifications should persist even if your application or OS subsequently fails. And, even if the application or OS fails in the middle of a transaction commit (or abort), the data on disk should be either in a consistent state, or there should be enough data available to bring your databases into a consistent state (via a recovery procedure, for example). You may, however, lose whatever data you were committing at the time of the failure, but your databases will be otherwise unaffected. </p> <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> <h3 class="title">Note</h3> <p> Be aware that many disks have a disk write cache and on some systems it is enabled by default. This means that a transaction can have committed, and to your application the data may appear to reside on disk, but the data may in fact reside only in the write cache at that time. This means that if the disk write cache is enabled and there is no battery backup for it, data can be lost after an OS crash even when maximum durability mode is in use. For maximum durability, disable the disk write cache or use a disk write cache with a battery backup. </p> </div> <p> Of course, if your <span class="emphasis"><em>disk</em></span> fails, then the transactional benefits described in this book are only as good as the backups you have taken. <span> By spreading your data and log files across separate disks, you can minimize the risk of data loss due to a disk failure, but even in this case it is possible to conjure a scenario where even this protection is insufficient (a fire in the machine room, for example) and you must go to your backups for protection. </span> </p> <p> Finally, by following the programming examples shown in this book, you can write your code so as to protect your data in the event that your code crashes. However, no programming API can protect you against logic failures in your own code; transactions cannot protect you from simply writing the wrong thing to your databases. </p> </div> <div class="sect2" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> <h3 class="title"><a id="apireq"></a>Application Requirements</h3> </div> </div> <div></div> </div> <p> In order to use transactions, your application has certain requirements beyond what is required of non-transactional protected applications. They are: </p> <div class="itemizedlist"> <ul type="disc"> <li> <p> Environments. </p> <p> Environments are optional for non-transactional applications, but they are required for transactional applications. </p> <p> Environments are optional for non-transactional applications that use the base API, but they are required for transactional applications. (Of course, applications that use the DPL always require the DPL.) </p> <p> Environment usage is described in detail in <a href="usingtxns.html">Transaction Basics</a>. </p> </li> <li> <p> Transaction subsystem. </p> <p> In order to use transactions, you must explicitly enable the transactional subsystem for your application, and this must be done at the time that your environment is first created. </p> </li> <li> <p> Logging subsystem. </p> <p> The logging subsystem is required for recovery purposes, but its usage also means your application may require a little more administrative effort than it does when logging is not in use. See <a href="filemanagement.html">Managing DB Files</a> for more information. </p> </li> <li> <p> <span>DbTxn</span> handles. </p> <p> In order to obtain the atomicity guarantee offered by the transactional subsystem (that is, combine multiple operations in a single unit of work), your application must use transaction handles. These handles are obtained from your <span>DbEnv</span> objects. They should normally be short-lived, and their usage is reasonably simple. To complete a transaction and save the work it performed, you call its <tt class="methodname">commit()</tt> method. To complete a transaction and discard its work, you call its <tt class="methodname">abort()</tt> method. </p> <p> In addition, it is possible to use auto commit if you want to transactional protect a single write operation. Auto commit allows a transaction to be used without obtaining an explicit transaction handle. See <a href="autocommit.html">Auto Commit</a> for information on how to use auto commit. </p> </li> <li> <p> <span>Database</span> open requirements. </p> <p> <span>In addition to using environments and initializing the correct subsystems, your</span> application must transaction protect the database opens<span>, and any secondary index associations,</span> if subsequent operations on the databases are to be transaction protected. The database open and secondary index association are commonly transaction protected using auto commit. </p> </li> <li> <p> Deadlock detection. </p> <p> Typically transactional applications use multiple threads of control when accessing the database. Any time multiple threads are used on a single resource, the potential for lock contention arises. In turn, lock contention can lead to deadlocks. See <a href="blocking_deadlocks.html">Locks, Blocks, and Deadlocks</a> for more information. </p> <p> Therefore, transactional applications must frequently include code for detecting and responding to deadlocks. Note that this requirement is not <span class="emphasis"><em>specific</em></span> to transactions – you can certainly write concurrent non-transactional DB applications. Further, not every transactional application uses concurrency and so not every transactional application must manage deadlocks. Still, deadlock management is so frequently a characteristic of transactional applications that we discuss it in this book. See <a href="txnconcurrency.html">Concurrency</a> for more information. </p> </li> </ul> </div> </div> <div class="sect2" lang="en" xml:lang="en"> <div class="titlepage"> <div> <div> <h3 class="title"><a id="multithread-intro"></a>Multi-threaded <span>and Multi-process</span> Applications</h3> </div> </div> <div></div> </div> <p> DB is designed to support multi-threaded <span>and multi-process</span> applications, but their usage means you must pay careful attention to issues of concurrency. Transactions help your application's concurrency by providing various levels of isolation for your threads of control. In addition, DB provides mechanisms that allow you to detect and respond to deadlocks (but strictly speaking, this is not limited to just transactional applications). </p> <p> <span class="emphasis"><em>Isolation</em></span> means that database modifications made by one transaction will not normally be seen by readers from another transaction until the first commits its changes. Different threads use different transaction handles, so this mechanism is normally used to provide isolation between database operations performed by different threads. </p> <p> Note that DB supports different isolation levels. For example, you can configure your application to see uncommitted reads, which means that one transaction can see data that has been modified but not yet committed by another transaction. Doing this might mean your transaction reads data "dirtied" by another transaction, but which subsequently might change before that other transaction commits its changes. On the other hand, lowering your isolation requirements means that your application can experience improved throughput due to reduced lock contention. </p> <p> For more information on concurrency, on managing isolation levels, and on deadlock detection, see <a href="txnconcurrency.html">Concurrency</a>. </p> </div> </div> </div> <div class="navfooter"> <hr /> <table width="100%" summary="Navigation footer"> <tr> <td width="40%" align="left"><a accesskey="p" href="preface.html">Prev</a> </td> <td width="20%" align="center"> <a accesskey="u" href="index.html">Up</a> </td> <td width="40%" align="right"> <a accesskey="n" href="recovery-intro.html">Next</a></td> </tr> <tr> <td width="40%" align="left" valign="top">Preface </td> <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> <td width="40%" align="right" valign="top"> Recoverability</td> </tr> </table> </div> </body> </html>