Resolution:
JMS specification has not defined explicitly when should the transaction start for a transacted session, i.e there is no API to do something like transaction.begin().

What has been specified implicitly in JMS spec:

=================================

A session may be specified as transacted. Each transacted session supports a single series of transactions. Each transaction groups a set of message sends and a set of message receives into an atomic unit of work. In effect, transactions organize a session's input message stream and output message stream into series of atomic units. When a transaction commits, its atomic unit of input is acknowledged and its associated atomic unit of output is sent. If a transaction rollback is done, the transaction's sent messages are destroyed and the session's input is automatically recovered.

The content of a transaction's input and output units is simply those messages that have been produced and consumed within the session's current transaction.

A transaction is completed using either its session's commit method or its session's rollback method. The completion of a session's current transaction automatically begins the next. The result is that a transacted session always has a current transaction within which its work is done.
=================================

Regarding, "The completion of a session's current transaction automatically begins the next". This means if you have received or published at least one message in a transaction, then another transaction is automatically started. If your client application has received or published messages and then the EMS fails over, it is expected you will see the exception, "Commit failed due to prior failure or after fault-tolerant switch" the next time for the first message that is processed after the fail over. The reason is that the transaction is started on fault tolerant server A but is committed on server B.

The right thing for the client to do is catching this error, and depending on what is being done in the transaction, the application logic need to be changed to accommodate this scenario:

1). If the application is receiving messages within the transaction, then the client needs no change. The message will be redelivered by EMS because of the previous session commit failed.

2). If the application involves sending messages in the transacted session, it may be required to add logic to retry that whole transaction explicitly after catching the exception

"Commit failed due to prior failure or after fault-tolerant switch".

JMS spec