tarantool / tarantool/tarantool

Implement single trigger list for transaction state changes

Open
#5,126 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

optimization qsync replication
Dominant language
Lua
Stars
3.7k
Forks
419
Avg merge
1d 23h
Merged PRs (30d)
88

Description

There are currently two states of a transaction: commit and rollback, both have triggers. With synchronous replication there is a new event - successfully WAL write, but not commit yet. This is needed in the applier so as to send an ACK to the master when this happens.
Current solution uses a hack with waking up the applier's fiber using fiber_wakeup(). However this is not a perfect solution - the writer fiber may not only wait for being woken up after WAL write, but also may be busy with other work, such as still sending a previous ACK. Its preliminary wakeup in this case leads to unnecessary wakeup and going back to sleep.
This can be solved by merging on_commit and on_rollback transaction triggers into one trigger list. The trigger list would contain all the triggers together, with a mask of events they want to listen to: commit, rollback, WAL write. When the triggers are run, the event is checked against the masks.
This not only allows to remove the hack with applier, but also makes struct txn 16 bytes smaller.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating struct txn and the on_commit, on_rollback, and fiber_wakeup paths in the transaction and replication code. Trace how the applier and writer fiber handle WAL writes, commits, rollbacks, and ACKs. Done means one masked trigger list handles all three events, the applier wakeup hack is removed, and struct txn is smaller without unnecessary wakeups.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
backend, databases, distributed-systems
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.