It looks like the problem is in org.jboss.tm.TransactionImpl.commit(). This method checks the transaction's status, if it is STATUS_ACTIVE then it, in the case of an XA transaction, prepares the resources (sets status to STATUS_PREPARED) and then commits the resources. During the commit for each of the resources the status is STATUS_COMMITTING. It appears a time-out happens exactly at this point. As the log shows:

WARN [org.jboss.tm.TransactionImpl] Transaction TransactionImpl:XidImpl[FormatId=257, GlobalId=doron/220, BranchQual=, localId=220] timed out. status=STATUS_COMMITING

On a transaction timeout when the transaction status is STATUS_COMMITING, org.jboss.tm.TransactionImpl.timedOut(Timeout timeout) sets the status to STATUS_MARKED_ROLLBACK. However, see the comment in the code:

271 case Status.STATUS_COMMITTING:
272 // This is very bad:
273 // We are in the second commit phase, and have decided
274 // to commit, but now we get a timeout and should rollback.
275 // So we end up with a mixed decision.
276 gotHeuristic(null, XAException.XA_HEURMIX);
277 status = Status.STATUS_MARKED_ROLLBACK;
278 return; // commit will fail

This is "very bad" because some of the resources may have already actually committed. It appears that is exactly what happened in this customer's case. Therefore, when org.jboss.tm.TransactionImpl.commit() checks the status again after the commit attempt and sees STATUS_MARKED_ROLLBACK it tries to rollback the resources. However, this resource has already committed and therefore doesn't recognize the Xid that it's given:

WARN [org.jboss.tm.TransactionImpl] XAException: tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=doron/220, BranchQual=, localId=220] errorCode=XAER_PROTO
org.jboss.resource.connectionmanager.JBossLocalXAException: wrong xid in rollback: expected: null, got: XidImpl[FormatId=257, GlobalId=doron/220, BranchQual=1, localId=220]
at org.jboss.resource.connectionmanager.TxConnectionManager$LocalXAResource.rollback(TxConnectionManager.java:1023)