Info
As part of the design for supporting additional transaction participants we agreed on leaving open transactions that would be reaped eventually.
This is currently safe to do since these transactions are essentially read-only and do not affect correctness.
However, this means we will unnecessarily hold some locks as part of the transaction that will only be released when we reap the leftover transaction. This also causes artificial delays if we want to perform any resharding/moveChunk operation since those will attempt to acquire with strong locks at one point or another.
Top User Comments
max.hirschhorn@10gen.com commented on Fri, 10 May 2024 22:37:55 +0000:
There are other message protocol scenarios which can lead to transactions being leaked until the abortExpiredTransactions background job causes the associated resources to be released. For example, it is possible for mongos to send an abortTransaction command to a shard concurrent with the command which starts the transaction is received/processed by that shard. This is because mongos broadcasts the abortTransaction command as soon as it learns from another shard the transaction would abort. When the {startTransaction: true} command is eventually processed by the shard, it'll lead to the transaction being started on the shard still. Recall that replica sets do not durably remember which transactions have aborted unless the transaction went through the two-phase commit protocol.
I think we should consider beyond $lookup and $graphLookup when exploring solutions to leaked transactions.
