There's no ordering between the prepare and commit/rollback messages, as the later are sent OOB.
With this in mind, the following transaction leak might happen:
Tx1 send prepare on nodes

1. the message reaches A and timeouts but hasn't yet been processed on B
2. The transaction originator reacts immediately to the timeout received from A without waiting the response from B and sends a rollback request
3. The rollback request is processed on A and B
4. The initial prepare is then processed on B

At this point we have an orphan transaction prepare on B.
Whilst this is not causing any inconsistencies, it keeps keys locked indefinitely and is a memory leak.

The solution would be to wait at 2 for all the prepare messages before sending the rollback.
Attached is a unit test to reproduce the issue.

Related mailing list thread: http://infinispan.markmail.org/search/#query:%20list%3Aorg.jboss.lists.infinispan-dev+page:1+mid:xgnmtee56jpqifs6+state:results