Transaction locks and conflicts

Hey there,

I’m really enjoying the new transactions released in v0.9, great work!

Currently if a transaction fails on a conflict, it’s up to the user to retry. Have you thought about introducing transaction locks at all? ie. if a transaction is going to conflict, wait until the other transaction(s) have finished and the conflict is resolved.

My use case is that I have many different trees being ingested in parallel which share a common root node. These trees ingest perfectly unless multiple trees try to connect to the root node at the same. My current solution is a backoff algorithm that eventually lets them connect from one another.

What are your thoughts on this?

Cheers,
Emerson

The problem that you have brought up is a good one – one on which many different approaches have been researched. For OLTP workloads, blocking transactions is bad for performance.

If we start blocking transactions, then a stuck transaction, or an uncommitted transaction (if the client crashes, and leaves pending txns behind) can bring the entire system to a halt. To solve this problem, if we then cancel the other transaction, after a timeout, then performance would degrade significantly, because every txn would try to wait and cancel the other – something that we’ve found to be bad for throughput (we had initially built that design, but then discarded it after testing).

The current system brings great performance, but does cause aborts. Aborts can be avoided by serializing txns when one knows that txns would collide with each other – but that’s something better done at the client side.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.