Late answer, but yes, the whole system is not consistent all the time, even though the commit commands probably are sent in parallel to all resources, some of them might take a bit longer to finalize their work and locks might not be freed at the exact same time

To commit a message on a queue by the queue resource manager might go faster than commiting a bunch of SQL commands for a database resource manager, leading up to that a "listener" gets a message and reads "old" data from the database (in the next transaction)

I know that this particular issue have been solved by some in the way that they add a relative time duration to not make the message is available immediately to the "listener" (a feature most queue managers support)