Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +

Prev	Chapter 19. - The Transaction Subsystem -	Chapter 19. The Transaction Subsystem	Next

@@ -42,17 +40,17 @@

- Transaction IDs + Transaction IDs
- Cursors + Cursors
- Multiple Threads of Control + Multiple Threads of Control

@@ -61,58 +59,71 @@

Transaction IDs

Transactions are identified by 31-bit unsigned integers, which means -there are just over two billion unique transaction IDs. When a database -environment is initially created or recovery is run, the transaction ID -name space is reset, and new transactions are numbered starting from -0x80000000 (2,147,483,648). The IDs will wrap if the maximum -transaction ID is reached, starting again from 0x80000000. The most -recently allocated transaction ID is the st_last_txnid value in -the transaction statistics information, and can be displayed by the -db_stat utility.

+ Transactions are identified by 31-bit unsigned integers, + which means there are just over two billion unique + transaction IDs. When a database environment is initially + created or recovery is run, the transaction ID name space + is reset, and new transactions are numbered starting from + 0x80000000 (2,147,483,648). The IDs will wrap if the + maximum transaction ID is reached, starting again from + 0x80000000. The most recently allocated transaction ID is + the st_last_txnid value + in the transaction statistics information, and can be + displayed by the db_stat utility. +

Cursors

When using transactions, cursors are localized to a single transaction. -That is, a cursor may not span transactions, and must be opened and -closed within a single transaction. In addition, intermingling -transaction-protected cursor operations and non-transaction-protected -cursor operations on the same database in a single thread of control is -practically guaranteed to deadlock because the locks obtained for -transactions and non-transactions can conflict.

+ When using transactions, cursors are localized to a + single transaction. That is, a cursor may not span + transactions, and must be opened and closed within a + single transaction. In addition, intermingling + transaction-protected cursor operations and + non-transaction-protected cursor operations on the same + database in a single thread of control is practically + guaranteed to deadlock because the locks obtained for + transactions and non-transactions can conflict. +

Multiple Threads of Control

Because transactions must hold all their locks until commit, a single -transaction may accumulate a large number of long-term locks during its -lifetime. As a result, when two concurrently running transactions -access the same database, there is strong potential for conflict. -Although Berkeley DB allows an application to have multiple outstanding -transactions active within a single thread of control, great care must -be taken to ensure that the transactions do not block each other (for -example, attempt to obtain conflicting locks on the same data). If two -concurrently active transactions in the same thread of control do -encounter a lock conflict, the thread of control will deadlock so that -the deadlock detector cannot detect the problem. In this case, there -is no true deadlock, but because the transaction on which a transaction -is waiting is in the same thread of control, no forward progress can be -made.

+ Because transactions must hold all their locks until + commit, a single transaction may accumulate a large number + of long-term locks during its lifetime. As a result, when + two concurrently running transactions access the same + database, there is strong potential for conflict. Although + Berkeley DB allows an application to have multiple + outstanding transactions active within a single thread of + control, great care must be taken to ensure that the + transactions do not block each other (for example, attempt + to obtain conflicting locks on the same data). If two + concurrently active transactions in the same thread of + control do encounter a lock conflict, the thread of + control will deadlock so that the deadlock detector cannot + detect the problem. In this case, there is no true + deadlock, but because the transaction on which a + transaction is waiting is in the same thread of control, + no forward progress can be made. +