BTM Implementation details

BTM is made of multiple modules which map as close as possible the JTA API.

This page contains descriptions of those components and how they work internally once BTM 1.3 will be released, as versions 1.2 and before did not fully respect this modularization.

Contents

Bitronix implementation specifics

XID

The JTA specification defines XID as an interface for which an implementation must be provided by the transaction manager. There are 3 important pieces composing a XID: the format ID, the Global TRansaction ID (GTRID) and the Branch QUALilifier (BQUAL).

Format ID

The format ID identifies the transaction manager which generated the XID. It basically is an integer which must be unique across all implementations. The BTM format ID simply is the int-encoded version of the "Btnx" ASCII string: 0x42746e78.

GTRID

The GTRID uniquely identifies the global transaction across all participating resources. The JTA spec says it must fit in a 64 bytes array and must be globally unique. The BTM implementation builds them by combining 3 data: the serverId, a timestamp and a sequence number.

BQUAL

The BQUAL uniquely identifies the local part of a global transaction inside a single participating resource. As for the GTRID the JTA spec says it must fit in a 64 bytes array and must be globally unique. The BTM BQUALs are built with the exact same format as the GTRID.

2PC engine

asynchronous2Pc

XA connection pooling framework

todo.

Disk journal

todo.

Recovery engine

currentNodeOnlyRecovery

This setting is very important when you're running a cluster of virtual machines all working on the same resource. In this case BTM will run multiple times in parallel, each node creating different transactions on the resource. Since the XIDs are guaranteed to be unique this isn't a problem for the transaction manager core.

The recovery engine on the other hand can get confused with this setup. Imagine this scenario: