liveBook · Manning

Lost write

As explained in ScyllaDB in Action

A lost write is an update that is overwritten by a concurrent update and therefore does not remain in the resulting data.

A lost write occurs when one concurrent update is overwritten by another and does not remain in the resulting data. section 6.1.2

ScyllaDB assigns each update a timestamp and converges on the value with the latest timestamp. If Edith and Emily concurrently edit an author bio, Emily’s later write wins and Edith’s update is lost. section 6.1.2

Ways to inspect or reduce the risk include:

  • Inspect cell write times with WRITETIME in a SELECT query. section 6.1.2
  • Use conditional updates or client-side coordination such as distributed locking when timestamp resolution is insufficient. section 6.1.2
  • Avoid manually specifying timestamps except for the stated data-migration case; an older timestamp cannot replace the current cell value. section 6.1.2

How ScyllaDB in Action covers it

How deep it goes
Traces timestamp-based resolution, cell-level write times, inspection, explicit timestamps, and prevention, but defers broader coordination details.
Examples
Uses Edith and Emily’s competing author-bio edits, WRITETIME output, and an obsolete timestamped bio update.
What it assumes
Assumes concurrent updates and ScyllaDB writes, while explaining timestamps and cell-level conflict resolution directly.
What you can do after
Diagnose lost writes with WRITETIME and reduce them using conditional updates or client-side coordination.
How it connects
Connects lost writes with concurrent operations, write timestamps, conditional updates, distributed locking, and replication.
Cover of ScyllaDB in Action
liveBookmanning.com
Read ScyllaDB in Action on liveBook Get the book at manning.com

Related concepts

This explainer was generated by Manning's knowledge graph from the text of ScyllaDB in Action. The section links point to the parts of the book it draws on.