abort-and-replay prepared XA transactions on the slave

Parallel applier guarantees that transactions are committed in a fixed predefined order (same as on the master). If trx1 must be committed before trx2, but the parallel applier executes them concurrently and trx2 happen to block trx1, then the applier aborts trx2, allows trx1 to finish, and then re-executes trx2.

This does not work if trx1 is an XA transaction. It becomes persistent on XA PREPARE, so it's XA PREPARE that must happen before trx2, not XA COMMIT. But XA PREPARE doesn't release all locks, so XA PREPARE is not a guarantee that a conflicting trx2 will be able to continue.

How can be fixed?