
A Comparison of Scalable Database Isolation Levels - evanweaver
https://fauna.com/blog/a-comparison-of-scalable-database-isolation-levels
======
ryanworl
This looks accurate except for the characterization that FoundationDB does not
offer strict serializability and/or external consistency. It does.

See 12:10 of this video from the FoundationDB Summit:
[https://youtu.be/EMwhsGsxfPU](https://youtu.be/EMwhsGsxfPU)

The Jepsen description of strict serializability is exactly what FoundationDB
offers: linearizability with a real time constraint. All transactions are
observed to have happened at a single point in time and a transaction observes
the effects of all previously committed transactions.

~~~
evanweaver
It seems like it should be able to offer strict, but the official docs suggest
otherwise and clearly distinguish it as different than serializable:

“FoundationDB provides the strongest possible consistency model, sequential
consistency (closely related to serializability from the database literature),
providing the greatest possible ease of development.”

[https://apple.github.io/foundationdb/consistency.html](https://apple.github.io/foundationdb/consistency.html)

In other places it says “serializable” but not strict.

Also, read conflicts are not added automatically on dependent reads of
conflict-free operations, violating serializability of conflict-full
operations.

Finally, if you query range offsets, is the entire prior range locked with a
read conflict or just the key at the offset? My understanding is the latter
which allows phantoms.

There’s a lot going on here and I would appreciate any clarification you can
offer.

~~~
Dave_Rosenthal
FoundationDB provides strict serializability for all types of operations, no
exceptions. You have to deliberately ask for lower (e.g. snapshot) levels.

>Read conflicts are not added automatically on dependent reads of conflict-
free operations, violating serializability of conflict-full operations.

"Conflict-free operations" presumably refer to the atomic ops. "dependent
reads" of such operations are simply not possible because these ops return no
data. From the docs: "Atomic operations do not expose the current value of the
key to the client..." Hence no serializability violation is possible.

>Finally, if you query range offsets, is the entire prior range locked with a
read conflict or just the key at the offset? My understanding is the latter
which allows phantoms.

Nope. There are no locks anyway (optimistic concurrency), but KeySelectors
(i.e. offsets), range reads, and any and all combinations thereof account for
all necessary transaction read dependencies. No phantoms possible.

To clarify: if you read a range, even if it is totally empty (returns 0
records), FoundationDB still ensures strict serializability against any other
transactions that touch that range.

~~~
evanweaver
The example here: [https://apple.github.io/foundationdb/developer-
guide.html?hi...](https://apple.github.io/foundationdb/developer-
guide.html?highlight=conflict%20free#conflict-ranges)

suggests that serializability is violated when atomic ops are mixed with
regular ops on the same key.

Note that transaction pipelining in Calvin does not have this issue.

