Transactions

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."

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, and each held message with its properties. Because it carries those properties, the list takes Read message contents (messages.read); without it the tab says you are not permitted.

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 cannot become an age, and the screen explains why

Artemis formats the preparation time with the JVM's own locale and time zone. There is no format to parse it against, so there is no arithmetic to do on it.

The time is therefore shown as the broker wrote it, with a note saying exactly that. 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

Where transactions are in doubt, the screen states the consequence: each 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, with a note saying why there is nothing else.

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

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.