A transaction across nodes

What happens inside when a TeselaDB transaction touches documents in ranges that live on different nodes.

TeselaDB

TeselaDB

TeselaDB team

2 min read

  • transactions
  • intents
  • isolation

A TeselaDB transaction can touch documents in several ranges and nodes and commits atomically, with snapshot isolation. Here you follow a transaction from its start until its writes become regular versions.

If everything falls in one range

If all the keys of the transaction fall in the same range, its leader commits it with a single write. It is the fastest case.

If it touches several ranges

If not, each range stores provisional versions, the intents. A transaction record decides whether it commits or aborts. That record lives in the range that covers its key, so it is also replicated with Raft.

intents in each range ──▶ transaction record: committed
                                   │
                                   ▼
                    intent resolution in the background

Once the record says "committed", the transaction is done. Your application gets the answer at that moment, and the work of turning each intent into a regular version, in every range the transaction touched, continues in the background without holding up the client.

When two transactions cross

A reader that finds a pending intent with a timestamp lower than its own pushes that transaction's minimum commit timestamp and reads the previous version, without waiting for the commit. A client transaction that finds someone else's intent fails with WriteConflict and the TransientTransactionError label, as in MongoDB. The drivers' withTransaction retries the transaction without you writing the retry.

Limits

A transaction aborts after 60 seconds by default. Its state has to fit in its coordinator's memory. A collector aborts the records of abandoned transactions. If you want to see it with code, the guide Inventory without overselling takes stock and creates an order in a single transaction.

All posts