BerkeleyDB from simple to deep [transferred from architect Yang Jian]

For (fail0;) {* Beginthetransaction. * if (retdbenv-txn_begin (dbenv, NULL, tid, 0 ))! 0) {dbenv-err (dbenv, ret, dbenv-txn_begin); exit (1);} * Storethekey. * switch (retdbp-put (dbp, tid, key, data, 0) {case0: * S

For (fail = 0;) {/* Begin the transaction. */if (ret = dbenv-txn_begin (dbenv, NULL, tid, 0 ))! = 0) {dbenv-err (dbenv, ret, dbenv-txn_begin); exit (1);}/* Store the key. */switch (ret = dbp-put (dbp, tid, key, data, 0) {case 0:/* S

For (fail = 0;) {/* Begin the transaction. */if (ret = dbenv-> txn_begin (dbenv, NULL, & tid, 0 ))! = 0) {dbenv-> err (dbenv, ret, "dbenv-> txn_begin"); exit (1 );}
/* Store the key. */switch (ret = dbp-> put (dbp, tid, & key, & data, 0) {case 0:/* Success: commit the change. */printf ("db: % s: key stored. \ n ", (char *) key. data); if (ret = tid-> commit (tid, 0 ))! = 0) {dbenv-> err (dbenv, ret, "DB_TXN-> commit"); exit (1) ;}return (0); case DB_LOCK_DEADLOCK: default: /* Failure: retry the operation. */if (t_ret = tid-> abort (tid ))! = 0) {dbenv-> err (dbenv, t_ret, "DB_TXN-> abort"); exit (1) ;}if (fail ++ = MAXIMUM_RETRY) return (ret); continue ;}}
 
   Berkeley DB consists of five major subsystems, including the access management subsystem, memory pool management subsystem, transaction subsystem, lock subsystem, and log subsystem. The access management subsystem is the core component of the Berkeley DB database process package, and other subsystems exist outside the Berkeley DB process package. Each subsystem supports different application levels.
1. Data Access Subsystem The Access Methods subsystem provides multiple support for creating and accessing database files. Berkeley DB provides the following four file storage methods: hash file, B-tree, fixed-length record (Queue), and variable-length record (Simple Storage Method Based on record numbers ), the application can select the most appropriate file organization structure. When creating a table, programmers can use any structure and perform hybrid operations on Different Storage types of files in the same application.
   Without transaction management, the modules in this subsystem can be used independently to provide fast and efficient data access services for applications. The Data Access Subsystem is suitable for applications that require fast file access without transactions.
 2. Memory Pool Management Subsystem  The Memory pool subsystem effectively manages the shared buffer used by Berkeley DB. It allows multiple processes or threads that access the database at the same time to share a high-speed cache, write the modified pages back to the file, and allocate memory space for the newly transferred pages. It can also be used by applications independently of the Berkeley DB system to allocate memory space for its own files and pages. The memory pool management subsystem is suitable for applications that require flexible, page-oriented, and buffered shared file access.
 3. Transaction Subsystem The Transaction subsystem provides the Transaction management function for Berkeley DB. It allows a group of modifications to the database to be considered as an atomic unit. This group of operations can be either performed in full or not. By default, the system will provide strict ACID transaction attributes, but applications can choose not to use the isolation guarantee made by the system. This subsystem uses the two-segment lock technology and the write-in log policy to ensure the correctness and consistency of database data. It can also be used independently by applications to protect transactions for data updates. The transaction subsystem is suitable for applications that require transaction data modification.    4. Lock Subsystem  The Locking subsystem provides the lock mechanism for Berkeley DB and provides the sharing control for multiple users to read and modify the same object for a single user. The Data Access Subsystem can be used to obtain the read and write permissions on pages or records. The transaction subsystem uses the locking mechanism to control the concurrency of multiple transactions.      This subsystem can also be used independently by applications. The lock subsystem is suitable for a flexible, fast, and configurable lock manager.  5. Log Subsystem    The log (Logging) subsystem adopts the log writing policy, which is used to support the transaction subsystem for data recovery to ensure data consistency. It is unlikely to be used independently by applications and can only be used as the call module of the transaction subsystem.
   The preceding parts constitute the entire Berkeley DB database system. The relationship between each part is shown in:
       In this model, the application directly calls the Data Access Subsystem and transaction management subsystem, which then calls the lower-level memory management subsystem, lock subsystem, and log subsystem.      Since several subsystems are relatively independent, applications can specify which data management services will be used at the beginning. You can use it all, or use only one part of it. For example, if an application needs to support multi-user concurrent operations without transaction management, it can only use the lock subsystem instead of transactions. Some applications may require a fast, single-user, B-tree storage structure without the transaction management function, then the application can invalidate the lock subsystem and transaction subsystem, which reduces the overhead.