v2.0.2

openglacier Core v2.0.2 — antaa palaa

Writes that no longer fail because of another collection.

---

Highlights

• Fix : A write conflicts only with a commit that changed what it read or wrote, no longer with any commit at all.
• Fix : A write refused for a conflict runs again by itself, up to five attempts.
• Fix : No durable event is lost in silence: one that cannot be stored is said in the ogd log.

---

Storage and writes

In v2.0.0 and v2.0.1, a transaction was refused as soon as any other commit happened between its start and its
commit, whatever that commit touched, and nothing ran it again. The Core itself writes in the background: the event
outbox deletes each event once delivered, just after the operation that published it (app.create, file.write,
an import…). The next write of the same client could then fail with
storage transaction conflict: Glacier generation changed before commit: data.mapping.save right after
app.create, imports right after their file was written, two users writing at the same time.

• Conflicts per collection. A transaction notes the collections it reads (get, scan, count) and those it
  writes. Another commit makes it conflict only if it changed one of them, created it or emptied it since the
  transaction's snapshot. A listing of all the collections counts as reading every one of them.
  • The collection a write reads its rows from is watched too, though its rows come through another snapshot
    (StorageTransaction::watch_collection).
  • A collection read only by a lookup is not watched: this is snapshot isolation, as in PostgreSQL's
    REPEATABLE READ.
  • A transaction whose writes were moved out of memory (spilled) also needs each collection it writes to be exactly
    as in its snapshot, not even compacted since.
  • The in-memory backend follows the same rule. Its commit now installs only the collections it wrote, instead of
    its whole copy of the store.
• Refused writes run again. A set, delete, load, into, insert or a group of writes run together that
  the storage refuses for a conflict is run again whole, on the state the other commit left, after 5, 10, 20 and
  40 ms (plus a random part of as much). A refused write committed nothing and sent nothing. The fifth refusal is
  returned. Other errors are not run again.
• Events. Storing a durable event in the outbox benefits from the same retries. One that still fails is
  reported in the ogd log (ogd events: the event … is lost), not only under OGD_DEBUG.

The conflict message now reads a collection of the transaction changed before commit.

Upgrading from 2.0.1

Nothing to do.

---

Full Changelog: v2.0.1...v2.0.2

Small core, long life.