Table of Contents
BDB XML offers a great deal of support for multi-threaded and multi-process applications even when transactions are not in use. Many of BDB XML's handles are thread-safe, or can be made thread-safe by providing the appropriate flag at handle creation time, and BDB XML provides a flexible locking subsystem for managing containers in a concurrent application. Further, BDB XML provides a robust mechanism for detecting and responding to deadlocks. All of these concepts are explored in this chapter.
Before continuing, it is useful to define a few terms that will appear throughout this chapter:
Thread of control
Refers to a thread that is performing work in your application. Typically, in this book that thread will be performing BDB XML operations.
Note that this term can also be taken to mean a separate process that is performing work — BDB XML supports multi-process operations on your containers.
Locking
When a thread of control obtains access to a shared resource, it is said to be locking that resource. Note that BDB XML supports both exclusive and non-exclusive locks. See Locks for more information.
Free-threaded
Data structures and objects are free-threaded if they can be shared across threads of control without any explicit locking on the part of the application. Some books, libraries, and programming languages may use the term thread-safe for data structures or objects that have this characteristic. The two terms mean the same thing.
For a description of free-threaded BDB XML objects, see Which BDB XML Handles are Free-Threaded.
Blocked
When a thread cannot obtain a lock because some other thread already holds a lock on that object, the lock attempt is said to be blocked. See Blocks for more information.
Deadlock
Occurs when two or more threads of control attempt to access conflicting resource in such a way as none of the threads can any longer may further progress.
For example, if Thread A is blocked waiting for a resource held by Thread B, while at the same time Thread B is blocked waiting for a resource held by Thread A, then neither thread can make any forward progress. In this situation, Thread A and Thread B are said to be deadlocked.
For more information, see Deadlocks.
The following describes to what extent and under what conditions individual handles are free-threaded.
Environment
Free-threaded so long as EnvironmentConfig.setThreaded() is set to true.
XmlManager
This class free-threaded.
XmlTransaction
Access must be serialized by the application across threads of control.
XmlContainer
This class is free-threaded.
XmlDocument
This class is not free-threaded, and it can be safely used only by one thread of control.
XmlIndexSpecification
This class is not free-threaded, and it can be safely used only by one thread of control.
XmlMetaDataIterator
This class is not free-threaded, and it can be safely used only by one thread of control.
XmlModify
During construction this class is not free-threaded. However, once constructed the object can be safely used across multiple threads of control.
XmlQueryContext
This class is not free-threaded, and it can be safely used only by one thread of control at a time.
XmlQueryExpression
This class is not free-threaded, and it can be safely used only by one thread of control at a time.
XmlResolver
If an application uses multiple threads, custom implementations of XmlResolver must be free threaded to allow multiple, simultaneous calls for resolution.
XmlResults
This class is not free-threaded, and it can be safely used only by one thread of control at a time.
XmlStatistics
This class is not free-threaded, and it can be safely used only by one thread of control at a time.
XmlTransaction
This class is not free-threaded, and it can be safely used only by one thread of control at a time.
XmlUpdateContext
This class is not free-threaded, and it can be safely used only by one thread of control at a time.
XmlValue
This class is not free-threaded, and it can be safely used only by one thread of control at a time.