The TransactionParticipant currently has at least 6 different code paths, which can abort a transaction, with slightly different implementation details between them:

• abortTransactionIfNotPrepared
• abortActiveTransaction
• abortActiveUnpreparedOrStashPreparedTransaction
• abortTransactionForStepUp
• abortPreparedTransactionForRollback
• invalidate

My suspicion is that this was done because there didn't use to be a good concurrency control between checking the state of the TransactionParticipant from outside and making abort decisions. Given that currently we have the Client lock concurrency control mechanism in place, all these different abort paths can be unified into some common denominator that they all share and the rest of the checks that they do can be pulled out into the calling sites.