Transactions

Updated 3 October 2026 · applies to 1.0.0 · Commercial

A distributed transaction that reached prepare and never received a commit or a rollback is in doubt. It holds its messages and its locks until somebody resolves it — which is why a queue can sit at a depth that never moves while nothing on its own screen looks wrong.

An empty list is the healthy state, and the screen says so

Rather than a blank table: "Nothing is in doubt — every distributed transaction this broker took part in was committed or rolled back by its transaction manager. This is the healthy state, not a missing list."

The In doubt tab, beside Heuristically committed and Heuristically rolled back: two prepared transactions, broka-probe-1792497244539-0 and broka-probe-1792497244539-1, each under its global id with its branch beneath, prepared at 20 Oct 2026, 11:54:04, and each holding +1 — one message it would add. — Both are held open until someone resolves them, and the ? beside the title states the consequence of resolving one here: the transaction manager did not make this decision, so the other branches may still go the other way.

Both are held open until someone resolves them, and the ? beside the title states the consequence of resolving one here: the transaction manager did not make this decision, so the other branches may still go the other way.

Each row names the transaction by its global id — the one the transaction manager and every other resource manager know it by — with its branch beneath. Clicking a row opens it: its ids, format and prepared time, what it would add and acknowledge, each held message with its properties, and at its foot Commit and Roll back. Because it carries those properties, the list takes Read message contents (messages.read); without it the tab says you are not permitted.

The detail of the in-doubt transaction broka-probe-1792497244539-0, prepared and unresolved: its global id, branch branch-0, format 1112689473, prepared 20 Oct 2026, 11:54:04 UTC, would add 1 and would acknowledge 0, and under Held messages one TextMessage marked Would add, with its properties in full — among them durable true, priority 4, the address orders.equity::orders.equity.new and its messageID — above Roll back, Commit and Close. — The broker names no destination for a held message; the address among its properties is the only lead to the queue it would land on.

The broker names no destination for a held message; the address among its properties is the only lead to the queue it would land on.

Holding shows two directions, not one number

A transaction's held work goes both ways, and a commit does opposite things with them: sends appear, receives disappear. A single figure of "3 messages" would hide which — so the column separates them.

The prepared time is read in the broker's own locale and time zone

Artemis writes the preparation time with its JVM's own locale and time zone, and names neither in the text. Broka reads both from the broker's runtime and turns the text back into a time, which the list and the detail then show like every other date in the console.

When that is not possible — the broker refused to say, or its text does not read in that locale — the time is shown as the broker wrote it, with a note saying so. It is worth more than an empty cell and it is not turned into something it cannot support.

The broker never names the queue a message was bound for

Its transaction detail carries the operation, the message type, and the message's own properties — and no destination.

So the properties are shown in full. An address appearing among them is the only answer available to "which queue is stuck because of this", and cutting them down would remove the one lead there is.

Resolving one is a decision the transaction manager did not make

The ? beside the screen's title states the consequence: each in-doubt transaction is holding its messages and its locks until resolved, and resolving it here means the other branches of the same distributed transaction may still go the other way.

The two heuristic lists are a record, not a problem

Heuristically committed and heuristically rolled back are transactions that were resolved locally, without the transaction manager's agreement. This broker may have decided differently from the other branches, and nothing reconciles that afterwards — which is exactly why they stay listed.

For these the broker gives only a Base64 id: no time, no branch, no messages. That is what the tabs show, and the same ? says why there is nothing else.

Resolving one: commit and roll back are asked as two different questions

Both are at the foot of the transaction's detail — click its row — where its held messages can be read first, and each is confirmed with what it will actually do, counted from that transaction:

Commit — its held messages are delivered and its acknowledgements take effect; the acknowledged messages leave their queues for good.
Roll back — its held messages are discarded and its acknowledgements are undone; those messages return to their queues for redelivery.

Both confirmations end with the same sentence, because it applies either way: the transaction manager did not decide this. Every other branch of the same distributed transaction may resolve the other way, and nothing reconciles them afterwards.

If the broker no longer has the transaction in doubt when the action runs — usually because the transaction manager finally decided — the console says that transaction was already resolved rather than reporting a success. A tick there would claim a decision this console did not make.

Both confirmations ask for a reason. Commit and Roll back appear only for someone allowed to change this broker, and not in a read-only environment or on a read-only connection; there the page says why instead. Resolving a transaction is recorded in the audit trail.