NNAAMMEE db_txn - DB transaction management SSYYNNOOPPSSIISS ##iinncclluuddee <> iinntt ttxxnn__ooppeenn((ccoonnsstt cchhaarr **ddiirr,, uu__iinntt3322__tt ffllaaggss,, iinntt mmooddee,, DDBB__EENNVV **ddbbeennvv,, DDBB__TTXXNNMMGGRR ****rreeggiioonnpp));; iinntt ttxxnn__bbeeggiinn((DDBB__TTXXNNMMGGRR **ttxxnnpp,, DDBB__TTXXNN **ppiidd,, DDBB__TTXXNN ****ttiidd));; iinntt ttxxnn__pprreeppaarree((DDBB__TTXXNN **ttiidd));; iinntt ttxxnn__ccoommmmiitt((DDBB__TTXXNN **ttiidd));; iinntt ttxxnn__aabboorrtt((DDBB__TTXXNN **ttiidd));; uu__iinntt3322__tt ttxxnn__iidd((DDBB__TTXXNN **ttiidd));; iinntt ttxxnn__cchheecckkppooiinntt((ccoonnsstt DDBB__TTXXNNMMGGRR **ttxxnnpp,, uu__iinntt3322__tt kkbbyyttee,, uu__iinntt3322__tt mmiinn));; iinntt ttxxnn__cclloossee((DDBB__TTXXNNMMGGRR **ttxxnnpp));; iinntt ttxxnn__uunnlliinnkk((ccoonnsstt cchhaarr **ddiirr,, iinntt ffoorrccee,, DDBB__EENNVV **ddbbeennvv));; iinntt ttxxnn__ssttaatt((DDBB__TTXXNNMMGGRR **ttxxnnpp,, DDBB__TTXXNN__SSTTAATT ****ssttaattpp,, vvooiidd **((**ddbb__mmaalllloocc))((ssiizzee__tt))));; DDEESSCCRRIIPPTTIIOONN The DB library is a family of groups of functions that provides a modular programming interface to transactions and record-oriented file access. The library includes support for transactions, locking, logging and file page caching, as well as various indexed access methods. Many of the functional groups (e.g., the file page caching functions) are useful independent of the other DB func- tions, although some functional groups are explicitly based on other functional groups (e.g., transactions and logging). For a general description of the DB package, see _d_b___i_n_t_r_o(3). This manual page describes the specific details of the DB transaction support. The _d_b___t_x_n functions are the library interface that pro- vides transaction semantics. Full transaction support is provided by a collection of modules that provide inter- faces to the services required for transaction processing. These services are recovery (see _d_b___l_o_g(3)), concurrency control (see _d_b___l_o_c_k(3)), and the management of shared data (see _d_b___m_p_o_o_l(3)). Transaction semantics can be applied to the access methods described in _d_b___o_p_e_n(3) through function call parameters. The model intended for transactional use (and the one that is used by the access methods) is write-ahead logging pro- vided by _d_b___l_o_g(3) to record both before- and after- images. Locking follows a two-phase protocol, with all locks being released at transaction commit. _t_x_n___o_p_e_n The _t_x_n___o_p_e_n function copies a pointer, to the transaction region identified by the ddiirreeccttoorryy _d_i_r, into the memory location referenced by _r_e_g_i_o_n_p. If the _d_b_e_n_v argument to _t_x_n___o_p_e_n was initialized using _d_b___a_p_p_i_n_i_t, _d_i_r is interpreted as described by _d_b___a_p_p_i_n_i_t(3). Otherwise, if _d_i_r is not NULL, it is interpreted relative to the current working directory of the process. If _d_i_r is NULL, the following environment variables are checked in order: ``TMPDIR'', ``TEMP'', and ``TMP''. If one of them is set, transaction region files are created relative to the directory it specifies. If none of them are set, the first possible one of the following directories is used: _/_v_a_r_/_t_m_p, _/_u_s_r_/_t_m_p, _/_t_e_m_p, _/_t_m_p, _C_:_/_t_e_m_p and _C_:_/_t_m_p. All files associated with the transaction region are cre- ated in this directory. This directory must already exist when transaction region_open is called. If the transaction region already exists, the process must have permission to read and write the existing files. If the transaction region does not already exist, it is optionally created and initialized. The _f_l_a_g_s and _m_o_d_e arguments specify how files will be opened and/or created when they don't already exist. The flags value is specified by oorr'ing together one or more of the following values: DB_CREATE Create any underlying files, as necessary. If the files do not already exist and the DB_CREATE flag is not specified, the call will fail. DB_THREAD Cause the DB_TXNMGR handle returned by the _t_x_n___o_p_e_n function to be useable by multiple threads within a single address space, i.e., to be ``free-threaded''. DB_TXN_NOSYNC On transaction commit, do not synchronously flush the log. This means that transactions exhibit the ACI (atomicity, consistency and isolation) properties, but not D (durability), i.e., database integrity will be maintained but it is possible that some number of the most recently committed transactions may be undone during recovery instead of being redone. The number of transactions that are potentially at risk is governed by how often the log is checkpointed (see _d_b___c_h_e_c_k_p_o_i_n_t(1)) and how many log updates can fit on a single log page. All files created by the transaction subsystem are created with mode _m_o_d_e (as described in _c_h_m_o_d(2)) and modified by the process' umask value at the time of creation (see _u_m_a_s_k(2)). The group ownership of created files is based on the system and directory defaults, and is not further specified by DB. The transaction subsystem is configured based on the _d_b_e_n_v argument to _t_x_n___o_p_e_n, which is a pointer to a structure of type DB_ENV (typedef'd in ). Applications will nor- mally use the same DB_ENV structure (initialized by _d_b___a_p_p_i_n_i_t(3)), as an argument to all of the subsystems in the DB package. References to the DB_ENV structure are maintained by DB, so it may not be discarded until the last close function, corresponding to an open function for which it was an argument, has returned. In order to ensure compatibility with future releases of DB, all fields of the DB_ENV structure that are not explicitly set should be initial- ized to 0 before the first time the structure is used. Do this by declaring the structure external or static, or by calling the C library routine _b_z_e_r_o(3) or _m_e_m_s_e_t(3). The fields of the DB_ENV structure used by _t_x_n___o_p_e_n are described below. If _d_b_e_n_v is NULL or any of its fields are set to 0, defaults appropriate for the system are used where possible. The following fields in the DB_ENV structure may be ini- tialized before calling _t_x_n___o_p_e_n: void *(*db_errcall)(char *db_errpfx, char *buffer); FILE *db_errfile; const char *db_errpfx; int db_verbose; The error fields of the DB_ENV behave as described for _d_b___a_p_p_i_n_i_t(3). DB_LOG *lg_info; The logging region that is being used for this trans- action environment. The _l_g___i_n_f_o field contains a return value from the function _l_o_g___o_p_e_n. LLooggggiinngg iiss rreeqquuiirreedd ffoorr ttrraannssaaccttiioonn eennvviirroonnmmeennttss,, aanndd iitt iiss aann eerrrroorr ttoo nnoott ssppeecciiffyy aa llooggggiinngg rreeggiioonn.. DB_LOCKTAB *lk_info; The locking region that is being used for this trans- action environment. The _l_k___i_n_f_o field contains a return value from the function _l_o_c_k___o_p_e_n. If _l_k___i_n_f_o is NULL, no locking is done in this transaction envi- ronment. u_int32_t tx_max; The maximum number of simultaneous transactions that are supported. This bounds the size of backing files and is used to derive limits for the size of the lock region and logfiles. When there are more than _t_x___m_a_x concurrent transactions, calls to _t_x_n___b_e_g_i_n may cause backing files to grow. If _t_x___m_a_x is 0, a default value is used. int (*tx_recover)(DB_LOG *logp, DBT *log_rec, DB_LSN *lsnp, int redo, void *info); A function that is called by _t_x_n___a_b_o_r_t during trans- action abort. This function takes five arguments: logp A pointer to the transaction log (DB_LOG *). log_rec A log record. lsnp A pointer to a log sequence number (DB_LSN *). redo An integer value that is set to one of the fol- lowing values: DB_TXN_BACKWARD_ROLL The log is being read backward to determine which transactions have been committed and which transactions were not (and should therefore be aborted during recovery). DB_TXN_FORWARD_ROLL The log is being played forward, any trans- action ids encountered that have not been entered into the list referenced by _i_n_f_o should be ignored. DB_TXN_OPENFILES The log is being read to open all the files required to perform recovery. DB_TXN_REDO Redo the operation described by the log record. DB_TXN_UNDO Undo the operation described by the log record. info An opaque pointer used to reference the list of transaction IDs encountered during recovery. If _r_e_c_o_v_e_r is NULL, the default is that only DB access method operations are transaction protected, and the default recover function will be used. The _t_x_n___o_p_e_n function returns the value of _e_r_r_n_o on fail- ure and 0 on success. _t_x_n___b_e_g_i_n The _t_x_n___b_e_g_i_n function creates a new transaction in the designated transaction manager, copying a pointer to a DB_TXN that uniquely identifies it into the memory refer- enced by _t_i_d. If the _p_i_d argument is non-NULL, the new transaction is a nested transaction with the transaction indicated by _p_i_d as its parent. Transactions may not span threads, i.e., each transaction must begin and end in the same thread, and each transac- tion may only be used by a single thread. The _t_x_n___b_e_g_i_n function returns the value of _e_r_r_n_o on fail- ure and 0 on success. _t_x_n___p_r_e_p_a_r_e The _t_x_n___p_r_e_p_a_r_e function initiates the beginning of a two phase commit. In a distributed transaction environment, _d_b can be used as a local transaction manager. In this case, the distributed transaction manager must send _p_r_e_- _p_a_r_e messages to each local manager. The local manager must then issue a _t_x_n___p_r_e_p_a_r_e and await its successful return before responding to the distributed transaction manager. Only after the distributed transaction manager receives successful responses from all of its _p_r_e_p_a_r_e mes- sages should it issue any _c_o_m_m_i_t messages. The _t_x_n___p_r_e_p_a_r_e function returns the value of _e_r_r_n_o on failure and 0 on success. _t_x_n___c_o_m_m_i_t The _t_x_n___c_o_m_m_i_t function ends the transaction specified by the _t_i_d argument. If DB_TXN_NOSYNC was not specified, a commit log record is written and flushed to disk, as are all previously written log records. If the transaction is nested, its locks are acquired by the parent transaction, otherwise its locks are released. Any applications that require strict two-phase locking must not release any locks explicitly, leaving them all to be released by _t_x_n___c_o_m_m_i_t. The _t_x_n___c_o_m_m_i_t function returns the value of _e_r_r_n_o on failure and 0 on success. _t_x_n___a_b_o_r_t The _t_x_n___a_b_o_r_t function causes an abnormal termination of the transaction. The log is played backwards and any nec- essary recovery operations are initiated through the _r_e_c_o_v_e_r function specified to _t_x_n___o_p_e_n. After recovery is completed, all locks held by the transaction are acquired by the parent transaction in the case of a nested transac- tion or released in the case of a non-nested transaction. As is the case for _t_x_n___c_o_m_m_i_t, applications that require strict two phase locking should not explicitly release any locks. The _t_x_n___a_b_o_r_t function returns the value of _e_r_r_n_o on fail- ure and 0 on success. _t_x_n___i_d The _t_x_n___i_d function returns the unique transaction id associated with the specified transaction. Locking calls made on behalf of this transaction should use the value returned from _t_x_n___i_d as the locker parameter to the _l_o_c_k___g_e_t or _l_o_c_k___v_e_c calls. _t_x_n___c_l_o_s_e The _t_x_n___c_l_o_s_e function detaches a process from the trans- action environment specified by the DB_TXNMGR pointer. All mapped regions are unmapped and any allocated resources are freed. Any uncommitted transactions are aborted. In addition, if the _d_i_r argument to _t_x_n___o_p_e_n was NULL and _d_b_e_n_v was not initialized using _d_b___a_p_p_i_n_i_t, all files cre- ated for this shared region will be removed, as if _t_x_n___u_n_l_i_n_k were called. When multiple threads are using the DB_TXNMGR handle con- currently, only a single thread may call the _t_x_n___c_l_o_s_e function. The _t_x_n___c_l_o_s_e function returns the value of _e_r_r_n_o on fail- ure and 0 on success. _t_x_n___u_n_l_i_n_k The _t_x_n___u_n_l_i_n_k function destroys the transaction region identified by the directory _d_i_r, removing all files used to implement the transaction region. (The directory _d_i_r is not removed.) If there are processes that have called _t_x_n___o_p_e_n without calling _t_x_n___c_l_o_s_e (i.e., there are pro- cesses currently using the transaction region), _t_x_n___u_n_l_i_n_k will fail without further action, unless the force flag is set, in which case _t_x_n___u_n_l_i_n_k will attempt to remove the transaction region files regardless of any processes still using the transaction region. The result of attempting to forcibly destroy the region when a process has the region open is unspecified. Pro- cesses using a shared memory region maintain an open file descriptor for it. On UNIX systems, the region removal should succeed and processes that have already joined the region should continue to run in the region without change, however processes attempting to join the transac- tion region will either fail or attempt to create a new region. On other systems, e.g., WNT, where the _u_n_l_i_n_k(2) system call will fail if any process has an open file descriptor for the file, the region removal will fail. In the case of catastrophic or system failure, database recovery must be performed (see _d_b___r_e_c_o_v_e_r(1) or the DB_RECOVER and DB_RECOVER_FATAL flags to _d_b___a_p_p_i_n_i_t(3)). Alternatively, if recovery is not required because no database state is maintained across failures, it is possi- ble to clean up a transaction region by removing all of the files in the directory specified to the _t_x_n___o_p_e_n func- tion, as transaction region files are never created in any directory other than the one specified to _t_x_n___o_p_e_n. Note, however, that this has the potential to remove files cre- ated by the other DB subsystems in this database environ- ment. The _t_x_n___u_n_l_i_n_k function returns the value of _e_r_r_n_o on failure and 0 on success. _t_x_n___c_h_e_c_k_p_o_i_n_t The _t_x_n___c_h_e_c_k_p_o_i_n_t function syncs the underlying memory pool, writes a checkpoint record to the log and then flushes the log. If either _k_b_y_t_e or _m_i_n is non-zero, the checkpoint is only done if more than _m_i_n minutes have passed since the last checkpoint, or if more than _k_b_y_t_e kilobytes of log data have been written since the last checkpoint. The _t_x_n___c_h_e_c_k_p_o_i_n_t function returns the value of _e_r_r_n_o on failure, 0 on success, and DB_INCOMPLETE if there were pages that needed to be written but that _m_e_m_p___s_y_n_c(3) was unable to write immediately. In this case, the _t_x_n___c_h_e_c_k_- _p_o_i_n_t call should be retried. The _t_x_n___c_h_e_c_k_p_o_i_n_t function is the underlying function used by the _d_b___c_h_e_c_k_p_o_i_n_t(1) utility. See the source code for the _d_b___c_h_e_c_k_p_o_i_n_t utility for an example of using _t_x_n___c_h_e_c_k_p_o_i_n_t in a UNIX environment. _t_x_n___s_t_a_t The _t_x_n___s_t_a_t function creates a statistical structure and copies a pointer to it into the user-specified memory location. Statistical structure are created in allocated memory. If _d_b___m_a_l_l_o_c is non-NULL, it is called to allocate the mem- ory, otherwise, the library function _m_a_l_l_o_c(3) is used. The function _d_b___m_a_l_l_o_c must match the calling conventions of the _m_a_l_l_o_c(3) library routine. Regardless, the caller is responsible for deallocating the returned memory. To deallocate the returned memory, free each returned memory pointer; pointers inside the memory do not need to be individually freed. The transaction region statistics are stored in a struc- ture of type DB_TXN_STAT (typedef'd in ). The fol- lowing DB_TXN_STAT fields will be filled in: u_int32_t st_refcnt; The number of references to the region. u_int32_t st_regsize; The size of the region. DB_LSN st_last_ckp; The LSN of the last checkpoint. DB_LSN st_pending_ckp; The LSN of any checkpoint that is currently in progress. If _s_t___p_e_n_d_i_n_g___c_k_p is the same as _s_t___l_a_s_t___c_k_p there is no checkpoint in progress. time_t st_time_ckp; The time the last completed checkpoint finished (as returned by _t_i_m_e(2)). u_int32_t st_last_txnid; The last transaction ID allocated. u_int32_t st_maxtxns; The maximum number of active transactions supported by the region. u_int32_t st_naborts; The number of transactions that have aborted. u_int32_t st_nactive; The number of transactions that are currently active. u_int32_t st_nbegins; The number of transactions that have begun. u_int32_t st_ncommits; The number of transactions that have committed. u_int32_t st_region_wait; The number of times that a thread of control was forced to wait before obtaining the region lock. u_int32_t st_region_nowait; The number of times that a thread of control was able to obtain the region lock without waiting. DB_TXN_ACTIVE *st_txnarray; A pointer to an array of _s_t___n_a_c_t_i_v_e DB_TXN_ACTIVE structures, describing the currently active transac- tions. The following fields of the DB_TXN_ACTIVE structure (typedef'd in ) will be filled in: u_int32_t txnid; The transaction ID as returned by _t_x_n___b_e_g_i_n(3). DB_LSN lsn; The LSN of the transaction-begin record. TTRRAANNSSAACCTTIIOONNSS Creating transaction protected applications using the DB access methods requires little system customization. In most cases, the default parameters to the locking, log- ging, memory pool, and transaction subsystems will suf- fice. Applications can use _d_b___a_p_p_i_n_i_t(3) to perform this initialization, or they may do it explicitly. Each database operation (i.e., any call to a function underlying the handles returned by _d_b___o_p_e_n(3) and _d_b___c_u_r_- _s_o_r(3)) is normally performed on behalf of a unique locker. If multiple calls on behalf of the same locker are desired, then transactions must be used. Once the application has initialized the DB subsystems that it is using, it may open the DB access method databases. For applications performing transactions, the databases must be opened after subsystem initialization, and cannot be opened as part of a transaction. Once the databases are opened, the application can group sets of operations into transactions, by surrounding the opera- tions with the appropriate _t_x_n___b_e_g_i_n, _t_x_n___c_o_m_m_i_t and _t_x_n___a_b_o_r_t calls. Databases accessed by a transaction must not be closed during the transaction. Note, it is not necessary to transaction protect read-only transactions, unless those transactions require repeatable reads. The DB access methods will make the appropriate calls into the lock, log and memory pool subsystems in order to guar- antee that transaction semantics are applied. When the application is ready to exit, all outstanding transactions should have been committed or aborted. At this point, all open DB files should be closed. Once the DB database files are closed, the DB subsystems should be closed, either explicitly or by calling _d_b___a_p_p_e_x_i_t(3). It is also possible to use the locking, logging and trans- action subsystems of DB to provide transaction semantics to objects other than those described by the DB access methods. In these cases, the application will need more explicit customization of the subsystems as well as the development of appropriate data-structure-specific recov- ery functions. For example, consider an application that provides trans- action semantics to data stored in plain UNIX files accessed using the _r_e_a_d(2) and _w_r_i_t_e(2) system calls. The operations for which transaction protection is desired are bracketed by calls to _t_x_n___b_e_g_i_n and _t_x_n___c_o_m_m_i_t. Before data are referenced, the application must make a call to the lock manager, _d_b___l_o_c_k, for a lock of the appropriate type (e.g., read) on the object being locked. The object might be a page in the file, a byte, a range of bytes, or some key. It is up to the application to ensure that appropriate locks are acquired. Before a write is performed, the application should acquire a write lock on the object, by making an appropriate call to the lock man- ager, _d_b___l_o_c_k. Then, the application should make a call to the log manager, _d_b___l_o_g, to record enough information to redo the operation in case of failure after commit and to undo the operation in case of abort. As discussed in the _d_b___l_o_g(3) manual page, the application is responsible for providing any necessary structure to the log record. For example, the application must understand what part of the log record is an operation code, what part identifies the file being modified, what part is redo information, and what part is undo information. After the log message is written, the application may issue the write system call. After all requests are issued, the application may call _t_x_n___c_o_m_m_i_t. When _t_x_n___c_o_m_m_i_t returns, the caller is guaranteed that all nec- essary log writes have been written to disk. At any time, the application may call _t_x_n___a_b_o_r_t, which will result in the appropriate calls to the _r_e_c_o_v_e_r func- tion to restore the ``database'' to a consistent pre- transaction state. (The recover function must be able to either re-apply or undo the update depending on the con- text, for each different type of log record.) If the application should crash, the recovery process uses the _d_b___l_o_g interface to read the log and call the _r_e_c_o_v_e_r function to restore the database to a consistent state. The _t_x_n___p_r_e_p_a_r_e function provides the core functionality to implement distributed transactions, but it does not manage the notification of distributed transaction man- agers. The caller is responsible for issuing _t_x_n___p_r_e_p_a_r_e calls to all sites participating in the transaction. If all responses are positive, the caller can issue a _t_x_n___c_o_m_m_i_t. If any of the responses are negative, the caller should issue a _t_x_n___a_b_o_r_t. In general, the _t_x_n___p_r_e_- _p_a_r_e call requires that the transaction log be flushed to disk. TTRRAANNSSAACCTTIIOONN IIDD LLIIMMIITTSS The transaction ID space in Berkeley DB is 2^31, or 2 bil- lion entries. It is possible that some environments may need to be aware of this limitation. Consider an applica- tion performing 600 transactions a second for 15 hours a day. The transaction ID space will run out in roughly 66 days: 2^31 / (600 * 15 * 60 * 60) = 66 Doing only 100 transactions a second exhausts the transac- tion ID space in roughly one year. The transaction ID space is reset each time recovery is run. If you reach the end of your transaction ID space, shut down your applications and restart them after running recovery (see _d_b___r_e_c_o_v_e_r(1) for more information). The most recently allocated transaction ID is the _s_t___l_a_s_t___t_x_n_i_d value in the transaction statistics informa- tion, and is displayed by the _d_b___s_t_a_t(1) utility. EENNVVIIRROONNMMEENNTT VVAARRIIAABBLLEESS The following environment variables affect the execution of _d_b___t_x_n: DB_HOME If the _d_b_e_n_v argument to _t_x_n___o_p_e_n was initialized using _d_b___a_p_p_i_n_i_t, the environment variable DB_HOME may be used as the path of the database home for the interpretation of the _d_i_r argument to _t_x_n___o_p_e_n, as described in _d_b___a_p_p_i_n_i_t(3). TMPDIR If the _d_b_e_n_v argument to _t_x_n___o_p_e_n was NULL or not initialized using _d_b___a_p_p_i_n_i_t, the environment vari- able TMPDIR may be used as the directory in which to create the transaction region, as described in the _t_x_n___o_p_e_n section above. EERRRROORRSS The _t_x_n___o_p_e_n function may fail and return _e_r_r_n_o for any of the errors specified for the following DB and library functions: close(2), db_version(3), fcntl(2), fflush(3), lseek(2), malloc(3), memcpy(3), memset(3), mmap(2), mun- map(2), open(2), sigfillset(3), sigprocmask(2), stat(2), strcpy(3), strdup(3), strerror(3), strlen(3), time(3), txn_unlink(3), unlink(2), and write(2). In addition, the _t_x_n___o_p_e_n function may fail and return _e_r_r_n_o for the following conditions: [EINVAL] An invalid flag value or parameter was specified. The DB_THREAD flag was specified and spinlocks are not implemented for this architecture. The _d_b_e_n_v parameter was NULL. [EAGAIN] The shared memory region was locked and (repeatedly) unavailable. The _t_x_n___b_e_g_i_n function may fail and return _e_r_r_n_o for any of the errors specified for the following DB and library functions: fcntl(2), fflush(3), log_put(3), lseek(2), mal- loc(3), memcpy(3), memset(3), mmap(2), munmap(2), str- error(3), and write(2). In addition, the _t_x_n___b_e_g_i_n function may fail and return _e_r_r_n_o for the following conditions: [ENOSPC] The maximum number of concurrent transactions has been reached. The _t_x_n___p_r_e_p_a_r_e function may fail and return _e_r_r_n_o for any of the errors specified for the following DB and library functions: fcntl(2), fflush(3), log_flush(3), and str- error(3). The _t_x_n___c_o_m_m_i_t function may fail and return _e_r_r_n_o for any of the errors specified for the following DB and library functions: fcntl(2), fflush(3), lock_vec(3), log_put(3), malloc(3), memcpy(3), and strerror(3). In addition, the _t_x_n___c_o_m_m_i_t function may fail and return _e_r_r_n_o for the following conditions: [EINVAL] The transaction was aborted. The _t_x_n___a_b_o_r_t function may fail and return _e_r_r_n_o for any of the errors specified for the following DB and library functions: DBenv->tx_recover(3), fcntl(2), fflush(3), lock_vec(3), log_get(3), memset(3), and strerror(3). [EINVAL] The transaction was already aborted. The _t_x_n___c_h_e_c_k_p_o_i_n_t function may fail and return _e_r_r_n_o for any of the errors specified for the following DB and library functions: fcntl(2), fflush(3), log_compare(3), log_put(3), malloc(3), memcpy(3), memp_sync(3), memset(3), strerror(3), and time(3). [EINVAL] An invalid flag value or parameter was specified. The _t_x_n___c_l_o_s_e function may fail and return _e_r_r_n_o for any of the errors specified for the following DB and library functions: close(2), fcntl(2), fflush(3), log_flush(3), munmap(2), strerror(3), and txn_abort(3). The _t_x_n___u_n_l_i_n_k function may fail and return _e_r_r_n_o for any of the errors specified for the following DB and library functions: close(2), fcntl(2), fflush(3), malloc(3), mem- cpy(3), memset(3), mmap(2), munmap(2), open(2), sig- fillset(3), sigprocmask(2), stat(2), strcpy(3), strdup(3), strerror(3), strlen(3), and unlink(2). In addition, the _t_x_n___u_n_l_i_n_k function may fail and return _e_r_r_n_o for the following conditions: [EBUSY] The shared memory region was in use and the force flag was not set. The _t_x_n___s_t_a_t function may fail and return _e_r_r_n_o for any of the errors specified for the following DB and library functions: fcntl(2), and malloc(3). SSEEEE AALLSSOO _L_I_B_T_P_: _P_o_r_t_a_b_l_e_, _M_o_d_u_l_a_r _T_r_a_n_s_a_c_t_i_o_n_s _f_o_r _U_N_I_X, Margo Seltzer, Michael Olson, USENIX proceedings, Winter 1992. BBUUGGSS Nested transactions are not yet implemented. _d_b___a_r_c_h_i_v_e(1), _d_b___c_h_e_c_k_p_o_i_n_t(1), _d_b___d_e_a_d_l_o_c_k(1), _d_b___d_u_m_p(1), _d_b___l_o_a_d(1), _d_b___r_e_c_o_v_e_r(1), _d_b___s_t_a_t(1), _d_b___i_n_t_r_o(3), _d_b___a_p_p_i_n_i_t(3), _d_b___c_u_r_s_o_r(3), _d_b___d_b_m(3), _d_b___i_n_t_e_r_n_a_l(3), _d_b___l_o_c_k(3), _d_b___l_o_g(3), _d_b___m_p_o_o_l(3), _d_b___o_p_e_n(3), _d_b___t_h_r_e_a_d(3), _d_b___t_x_n(3)