From 780b92ada9afcf1d58085a83a0b9e6bc982203d1 Mon Sep 17 00:00:00 2001 From: Lorry Tar Creator Date: Tue, 17 Feb 2015 17:25:57 +0000 Subject: Imported from /home/lorry/working-area/delta_berkeleydb/db-6.1.23.tar.gz. --- docs/programmer_reference/transapp_inc.html | 80 +++++++++++++++++------------ 1 file changed, 46 insertions(+), 34 deletions(-) (limited to 'docs/programmer_reference/transapp_inc.html') diff --git a/docs/programmer_reference/transapp_inc.html b/docs/programmer_reference/transapp_inc.html index 92fbcdef..7ad5eeb3 100644 --- a/docs/programmer_reference/transapp_inc.html +++ b/docs/programmer_reference/transapp_inc.html @@ -14,7 +14,7 @@
-

Library Version 11.2.5.3

+

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +
Prev Chapter 11.  - Berkeley DB Transactional Data Store Applications - Chapter 11.  Berkeley DB Transactional Data Store Applications  Next
@@ -38,34 +36,45 @@
-

The third reason listed for using transactions was isolation. -Consider an application suite in which multiple threads of control -(multiple processes or threads in one or more processes) are changing -the values associated with a key in one or more databases. Specifically, -they are taking the current value, incrementing it, and then storing it -back into the database.

-

Such an application requires isolation. Because we want to change a value -in the database, we must make sure that after we read it, no other thread -of control modifies it. For example, assume that both thread #1 and -thread #2 are doing similar operations in the database, where thread #1 -is incrementing records by 3, and thread #2 is incrementing records by -5. We want to increment the record by a total of 8. If the operations -interleave in the right (well, wrong) order, that is not what will -happen:

+

+ The third reason listed for using transactions was + isolation. Consider an application + suite in which multiple threads of control (multiple processes + or threads in one or more processes) are changing the values + associated with a key in one or more databases. Specifically, + they are taking the current value, incrementing it, and then + storing it back into the database. +

+

+ Such an application requires isolation. Because we want to + change a value in the database, we must make sure that after + we read it, no other thread of control modifies it. For + example, assume that both thread #1 and thread #2 are doing + similar operations in the database, where thread #1 is + incrementing records by 3, and thread #2 is incrementing + records by 5. We want to increment the record by a total of 8. + If the operations interleave in the right (well, wrong) order, + that is not what will happen: + 

thread #1  read record: the value is 2
 thread #2  read record: the value is 2
 thread #2  write record + 5 back into the database (new value 7)
 thread #1  write record + 3 back into the database (new value 5)
-

As you can see, instead of incrementing the record by a total of 8, -we've incremented it only by 3 because thread #1 overwrote thread #2's -change. By wrapping the operations in transactions, we ensure that this -cannot happen. In a transaction, when the first thread reads the -record, locks are acquired that will not be released until the -transaction finishes, guaranteeing that all writers -will block, waiting for the first thread's transaction to complete (or -to be aborted).

-

Here is an example function that does transaction-protected increments -on database records to ensure isolation:

+

+ As you can see, instead of incrementing the record by a + total of 8, we've incremented it only by 3 because thread #1 + overwrote thread #2's change. By wrapping the operations in + transactions, we ensure that this cannot happen. In a + transaction, when the first thread reads the record, locks are + acquired that will not be released until the transaction + finishes, guaranteeing that all writers will block, waiting + for the first thread's transaction to complete (or to be + aborted). +

+

+ Here is an example function that does transaction-protected + increments on database records to ensure isolation: + 

int
 main(int argc, char *argv)
 {
@@ -180,12 +189,15 @@ add_color(DB_ENV *dbenv, DB *dbp, char *color, int increment)
         }
     }
 }
-

The DB_RMW flag in the DB->get() call specifies a write lock -should be acquired on the key/data pair, instead of the more obvious read -lock. We do this because the application expects to write the key/data -pair in a subsequent operation, and the transaction is much more likely to -deadlock if we first obtain a read lock and subsequently a write lock, than -if we obtain the write lock initially.

+

+ The DB_RMW flag in the DB->get() call specifies a write lock + should be acquired on the key/data pair, instead of the more + obvious read lock. We do this because the application expects + to write the key/data pair in a subsequent operation, and the + transaction is much more likely to deadlock if we first obtain + a read lock and subsequently a write lock, than if we obtain + the write lock initially. +

-- cgit v1.2.1