Implement reference transaction voting in TransactionManager
Gitaly's TransactionManager
needs to be extended to support voting before accepting transactions. This is required to retain the behavior of Praefect's transactions after enabling the WAL logic.
The other hooks, pre-receive
, update
, and post-receive
, can still remain outside of the TransactionManager
. They don't involve any locking and run concurrently with other transactions.
The reference-transaction
hook is different. It expects that the references, or other resources for more general voting, are locked and verified in the prepared
phase before voting. They should remain locked until the transaction is committed. This synchronization needs to happen inside the TransactionManager
like all other reference verification, locking and modifications.
First iteration can do the voting in the critical section when verifying references and logging the transaction. This should behave correctly but would effectively sequentialize all voting which is likely to be a performance problem.
We can later improve upon this by implementing better locking semantics that would allow the voting of disjoint updates to happen concurrently.