Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Make asynchronously terminated transactions release their locks
Previously, asynchronously terminated transactions would only release their locks after checking the termination flag, realising that the transaction had been asynchronously terminated, and then closing their transaction. This process required that the terminated threads would cooperate and clean up the resources they are holding. One such resource, a particularly precious one, is the locks acquired by the given transaction. If a transaction never went into the kernel, it would never discover that it had been terminated, and thus could hold on to their locks practically indefinitely, in turn blocking other transactions stuck on those locks from making process. The reason we did it this way, is because transactions might need to also grab locks during commit, and we cannot allow asynchronous termination of transactions that have already started their commit process. Transactions that have started committing will presumably relinquish their resource pretty soon anyway. So to do this differently, to solve both the problem of letting killed transactions relinquish their locks sooner, and to avoid killing transactions during commit, a new lock client state called "PREPARE" is introduced. The lock client is moved to the PREPARE state when the transaction enters the PREPARE phase. Once the lock client is in PREPARE, it can no longer be moved to the STOPPED state via asynchronous termination. In the PREPARE state, the lock client will still allow new locks to be taken and released, and the client will move to the STOPPED state when it is closed. This mechanism protects the lock client and the commit process, and it allows us to release all locks held by a lock client, when we asynchronously terminate with the stop() method it before the prepare phase. This means that transaction timeout is now also effective on transactions that are stuck waiting for network traffic, or other resources external to the database itself, for instance. And it means that terminating a transaction will now immediately allow any other transactions, that are otherwise stuck waiting for locks held by the terminated transaction, to make progress. In this process, a bug has also been fixed in the listQueries procedure, where the lock count would come from whichever lock client was used to *plan* the query, and not the lock client associated with the running transaction. The reason this bug happened, is that the `StackingQueryRegistrationOperations` eagerly grabbed the lock client from the current statement locks, when creating a lambda for getting the current lock count. The fix for that is to make the lambda capture the `statement` reference, instead of the reference coming out of the `statement.locks()` call.
- Loading branch information
Showing
19 changed files
with
369 additions
and
72 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.