The old method of queuing dropped transactions for revert and then actually doing the revert the next time the transaction is used in an async context can leave idle transactions unreverted for a long time. This may seem ok if the connection is not otherwise being used. However, this can cause SERIALIZABLE READ ONLY DEFERRABLE transactions to block indefinitely waiting to acquire a snapshot, since the database sees that there is a writable transaction in progress indefinitely.
The new method ensures transactions are always reverted soon after they are dropped by running the revert in a background task. If the connection is acquired again before the revert has completed, it will block on the cmpletion of the background task, to ensure the connection is not used while the old transaction is still in progress.
Yep, the MutexGuard ensures that each Connection is completely owned by its Transaction. And the Transaction interface only permits use that commits or reverts the transaction before releasing it
The old method of queuing dropped transactions for revert and then actually doing the revert the next time the transaction is used in an async context can leave idle transactions unreverted for a long time. This may seem ok if the connection is not otherwise being used. However, this can cause
SERIALIZABLE READ ONLY DEFERRABLE
transactions to block indefinitely waiting to acquire a snapshot, since the database sees that there is a writable transaction in progress indefinitely.The new method ensures transactions are always reverted soon after they are dropped by running the revert in a background task. If the connection is acquired again before the revert has completed, it will block on the cmpletion of the background task, to ensure the connection is not used while the old transaction is still in progress.