Andreas already has the answer. I'd just like to add some detail for people like me, who may think STATUS_NO_TRANSACTION is not an intuitive state for a completed transaction, since we also have a STATUS_COMMITTED in the list.
Here are all the states that a transaction can possess as listed in EE6 javadoc;
STATUS_ACTIVE 0
STATUS_COMMITTED 3
STATUS_COMMITTING 8
STATUS_MARKED_ROLLBACK 1
STATUS_NO_TRANSACTION 6
STATUS_PREPARED 2
STATUS_PREPARING 7
STATUS_ROLLEDBACK 4
STATUS_ROLLING_BACK 9
STATUS_UNKNOWN 5
On the javadocs, it clearly states that we'll get an STATUS_NO_TRANSACTION after the transaction completes (commit or rollback)
static final int STATUS_NO_TRANSACTION
No transaction is currently associated with the target object.
This will occur after a transaction has completed.
So when do we have STATUS_ROLLEDBACK and STATUS_COMMITTED? Javadocs, similar for these two states, reveal that these corresponds to somehow problematic states, if there were no problems you'd get a STATUS_NO_TRANSACTION instead;
static final int STATUS_COMMITTED
A transaction is associated with the target object and it has been committed.
It is likely that heuristics exist; otherwise, the transaction
would have been destroyed and NoTransaction returned.
Heuristics?
Here is the definition;
A heuristic completion (or heuristic decision) occurs when a resource
makes a unilateral decision during the completion stage of a
distributed transaction to commit or rollback updates. This can leave
distributed data in an indeterminate state. Network failures or
resource timeouts are possible causes for heuristic completion.
That means, simply stated, something went wrong with your XA transaction, possibly due to a transient condition like network, timeouts etc.
Fair enough.
Also, it may worth noting that, how WebSphere deals with these heuristic completions can be configured via heuristic-related properties outlined at Configuring transaction properties for an application server