In order to use transactions, your application has certain requirements beyond what is required of non-transactional protected applications. They are:
Environments
Environments are optional for non-transactional applications, but they are required for transactional applications.
Environments are always used by Figaro, but for transactional applications you must instantiate and manage your FigaroEnv object independently of your XmlManager.
Environment usage is described in detail in Transaction Basics.
Transaction Subsystem
In order to use transactions, you must explicitly enable the transactional subsystem for your application, and this must be done at the time that your environment is first created.
Logging Subsystem
The logging subsystem is required for recovery purposes, but its usage also means your application may require a little more administrative effort than it does when logging is not in use. See Managing Figaro BDB XML Files for more information.
XmlTransaction Handles
In order to obtain the atomicity guarantee offered by the transactional subsystem (that is, combine multiple operations in a single unit of work), your application must use transaction handles. These handles are obtained from your XmlManager objects. They should normally be short-lived, and their usage is reasonably simple. To complete a transaction and save the work it performed, you call its Commit method. To complete a transaction and discard its work, you call its Abort method.
In addition, it is possible to use auto commit if you want to transactionally protect a single write operation. Auto commit allows a transaction to be used without obtaining an explicit transaction handle. See Auto-Commit for information on how to use auto commit.
Container Open Requirements
In addition to using environments and initializing the correct subsystems, your application must transaction protect the container opens if subsequent operations on the containers are to be transaction protected. The container open and secondary index association are commonly transaction protected using auto commit.
Deadlock Detection
Typically transactional applications use multiple threads of control when accessing the database. Any time multiple threads are used on a single resource, the potential for lock contention arises. In turn, lock contention can lead to deadlocks. See Locks, Blocks, and Deadlocks for more information.
Therefore, transactional applications must frequently include code for detecting and responding to deadlocks. Note that this requirement is not specific to transactions – you can certainly write concurrent non-transactional Figaro applications. Further, not every transactional application uses concurrency and so not every transactional application must manage deadlocks. Still, deadlock management is so frequently a characteristic of transactional applications that we discuss it in this topic. See Concurrency for more information.
See Also
