diff options
Diffstat (limited to 'db/docs/gsg_txn/JAVA/introduction.html')
| -rw-r--r-- | db/docs/gsg_txn/JAVA/introduction.html | 441 |
1 files changed, 441 insertions, 0 deletions
diff --git a/db/docs/gsg_txn/JAVA/introduction.html b/db/docs/gsg_txn/JAVA/introduction.html new file mode 100644 index 000000000..d2315cd21 --- /dev/null +++ b/db/docs/gsg_txn/JAVA/introduction.html @@ -0,0 +1,441 @@ +<?xml version="1.0" encoding="ISO-8859-1" 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=ISO-8859-1" /> + <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> + <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> + 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>Transaction</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>Environment</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> |