Chapter 13.  Distributed Transactions

Table of Contents

Introduction
Berkeley DB XA Implementation
Building a Global Transaction Manager
Communicating with multiple Berkeley DB environments
Recovering from GTM failure
Managing the Global Transaction ID (GID) name space
Maintaining state for each distributed transaction.
Recovering from the failure of a single environment
Recovering from GTM failure
XA Introduction
Configuring Berkeley DB with the Tuxedo System
Update the Resource Manager File in Tuxedo
Build the Transaction Manager Server
Update the UBBCONFIG File
Restrictions on XA Transactions
XA: Frequently Asked Questions

Introduction

An application must use distributed transactions whenever it wants transactional semantics either across operations in multiple Berkeley DB environments (even if they are on the same machine) or across operations in Berkeley DB and some other database systems (for example, Oracle server). Berkeley DB provides support for distributed transactions using a two-phase commit protocol. In order to use the two-phase commit feature of Berkeley DB, an application must either implement its own global transaction manager or use an XA-compliant transaction manager such as Oracle Tuxedo (as Berkeley DB can act as an XA-compliant resource manager).

This chapter explains Berkeley DB's XA-compliant resource manager, which can be used in any X/Open distributed transaction processing system, and explains how to configure Oracle Tuxedo to use the Berkeley DB resource manager.