diff options
| author | Lorry Tar Creator <lorry-tar-importer@baserock.org> | 2015-02-17 17:25:57 +0000 |
|---|---|---|
| committer | <> | 2015-03-17 16:26:24 +0000 |
| commit | 780b92ada9afcf1d58085a83a0b9e6bc982203d1 (patch) | |
| tree | 598f8b9fa431b228d29897e798de4ac0c1d3d970 /docs/programmer_reference/transapp_term.html | |
| parent | 7a2660ba9cc2dc03a69ddfcfd95369395cc87444 (diff) | |
| download | berkeleydb-master.tar.gz | |
Diffstat (limited to 'docs/programmer_reference/transapp_term.html')
| -rw-r--r-- | docs/programmer_reference/transapp_term.html | 116 |
1 files changed, 71 insertions, 45 deletions
diff --git a/docs/programmer_reference/transapp_term.html b/docs/programmer_reference/transapp_term.html index ef80e7d1..9fd1c641 100644 --- a/docs/programmer_reference/transapp_term.html +++ b/docs/programmer_reference/transapp_term.html @@ -14,7 +14,7 @@ <body> <div xmlns="" class="navheader"> <div class="libver"> - <p>Library Version 11.2.5.3</p> + <p>Library Version 12.1.6.1</p> </div> <table width="100%" summary="Navigation header"> <tr> @@ -22,9 +22,7 @@ </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="transapp_why.html">Prev</a> </td> - <th width="60%" align="center">Chapter 11. - Berkeley DB Transactional Data Store Applications - </th> + <th width="60%" align="center">Chapter 11. Berkeley DB Transactional Data Store Applications </th> <td width="20%" align="right"> <a accesskey="n" href="transapp_fail.html">Next</a></td> </tr> </table> @@ -38,70 +36,98 @@ </div> </div> </div> - <p>Here are some definitions that will be helpful in understanding -transactions:</p> + <p> + Here are some definitions that will be helpful in + understanding transactions: + </p> <div class="variablelist"> <dl> <dt> <span class="term">Thread of control</span> </dt> - <dd>Berkeley DB is indifferent to the type or style of threads being used by the -application; or, for that matter, if threads are being used at all — -because Berkeley DB supports multiprocess access. In the Berkeley DB documentation, -any time we refer to a <span class="emphasis"><em>thread of control</em></span>, it can be read as -a true thread (one of many in an application's address space) or a -process.</dd> + <dd> + Berkeley DB is indifferent to the type or style + of threads being used by the application; or, for that + matter, if threads are being used at all — + because Berkeley DB supports multiprocess access. In + the Berkeley DB documentation, any time we refer to a + <span class="emphasis"><em>thread of control</em></span>, it can be + read as a true thread (one of many in an application's + address space) or a process. + </dd> <dt> <span class="term">Free-threaded</span> </dt> - <dd>A Berkeley DB handle that can be used by multiple threads simultaneously -without any application-level synchronization is called -<span class="emphasis"><em>free-threaded</em></span>.</dd> + <dd> + A Berkeley DB handle that can be used by + multiple threads simultaneously without any + application-level synchronization is called + <span class="emphasis"><em>free-threaded</em></span>. + </dd> <dt> <span class="term">Transaction</span> </dt> - <dd>A <span class="emphasis"><em>transaction</em></span> is a one or more operations on one or more -databases that should be treated as a single unit of work. For example, -changes to a set of databases, in which either all of the changes must be -applied to the database(s) or none of them should. Applications specify -when each transaction starts, what database operations are included in -it, and when it ends.</dd> + <dd> + A <span class="emphasis"><em>transaction</em></span> is a one or + more operations on one or more databases that should + be treated as a single unit of work. For example, + changes to a set of databases, in which either all of + the changes must be applied to the database(s) or none + of them should. Applications specify when each + transaction starts, what database operations are + included in it, and when it ends. + </dd> <dt> <span class="term">Transaction abort/commit</span> </dt> - <dd>Every transaction ends by <span class="emphasis"><em>committing</em></span> or <span class="emphasis"><em>aborting</em></span>. -If a transaction commits, Berkeley DB guarantees that any database changes -included in the transaction will never be lost, even after system or -application failure. If a transaction aborts, or is uncommitted when -the system or application fails, then the changes involved will never -appear in the database.</dd> + <dd> + Every transaction ends by + <span class="emphasis"><em>committing</em></span> or + <span class="emphasis"><em>aborting</em></span>. If a transaction + commits, Berkeley DB guarantees that any database + changes included in the transaction will never be + lost, even after system or application failure. If a + transaction aborts, or is uncommitted when the system + or application fails, then the changes involved will + never appear in the database. + </dd> <dt> <span class="term">System or application failure</span> </dt> - <dd><span class="emphasis"><em>System or application failure</em></span> is the phrase we use to -describe something bad happening near your data. It can be an -application dumping core, being interrupted by a signal, the disk -filling up, or the entire system crashing. In any case, for whatever -reason, the application can no longer make forward progress, and its -databases are left in an unknown state.</dd> + <dd><span class="emphasis"><em>System or application + failure</em></span> is the phrase we use to + describe something bad happening near your data. It + can be an application dumping core, being interrupted + by a signal, the disk filling up, or the entire system + crashing. In any case, for whatever reason, the + application can no longer make forward progress, and + its databases are left in an unknown state. + </dd> <dt> <span class="term">Recovery</span> </dt> - <dd><span class="emphasis"><em>Recovery</em></span> is what makes the database consistent after a system -or application failure. The recovery process includes review of log -files and databases to ensure that the changes from each committed -transaction appear in the database, and that no changes from an -unfinished (or aborted) transaction do. Whenever system or application -failure occurs, applications must usually run recovery.</dd> + <dd><span class="emphasis"><em>Recovery</em></span> is what makes the + database consistent after a system or application + failure. The recovery process includes review of log + files and databases to ensure that the changes from + each committed transaction appear in the database, and + that no changes from an unfinished (or aborted) + transaction do. Whenever system or application failure + occurs, applications must usually run + recovery. + </dd> <dt> <span class="term">Deadlock</span> </dt> - <dd><span class="emphasis"><em>Deadlock</em></span>, in its simplest form, happens when one thread of -control owns resource A, but needs resource B; while another thread of -control owns resource B, but needs resource A. Neither thread of -control can make progress, and so one has to give up and release all -its resources, at which time the remaining thread of control can make -forward progress.</dd> + <dd><span class="emphasis"><em>Deadlock</em></span>, in its simplest + form, happens when one thread of control owns resource + A, but needs resource B; while another thread of + control owns resource B, but needs resource A. Neither + thread of control can make progress, and so one has to + give up and release all its resources, at which time + the remaining thread of control can make forward + progress. + </dd> </dl> </div> </div> |