Implement transaction in client side

ScyllaDB
, , , ,
2

I am aware that we can use GSI, but I’m not doing that for a variety of reasons.

Note we do support synchronous GSIs.

  • INSERT INTO tx: id is random UUID, image, is the serialized bytes, and status is PENDING. set created and updated to current time. At this point if node fails, we are left with an orphan record in tx, which I figure is not a big deal.

You may also TTL it, as ideally this tx shouldn’t live for too long anyway. You definitely want to TTL the lock field for all items, in case a worker dies and you don’t hold it for too long (unless you plan to come up with a custom-made unlocking mechanism)

  • make the change for all items, again using conditions for concurrency conflict and ensuring lock is still there.
  • set the tx status to committed, again using conditions
  • remove the lock on each item, or if lock_tmp is true, delete the item.
  • set tx status to completed. Done.

Looks fine, could maybe be optimized a few. FWIW, Service Resilience — part 3: Distributed Locking | by Martina Alilovic Rojnic | ReversingLabs Engineering | Medium is a nice write-up on how ReversingLabs did it with ScyllaDB, so it may also help you out.

Also a side question: can I regard the result from a LWT query as of quorum consistency?

See SERIAL CONSISTENCY in Lightweight Transactions | ScyllaDB Docs, though yea - it requires a majority for consensus.

1 Like