3 ms·

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

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.

ryanworl 8y ago
Range reads do create conflict ranges for the entire range even if you use offsets. Not only does it create the conflict range, I think it actually does the work of reading the data, it just isn’t returned to you. This is why it is an O(N) operation with the size of the offset. Not sure of the exact scenario you’re envisioning with atomic ops, but they’re essentially blind writes from what I understand. I don’t know how blind writes relate to transaction isolation, but I’m sure someone can fill in the details.
- Dave_Rosenthal 8y ago
  >Not only does it create the conflict range, I think it actually does the work of reading the data, it just isn’t returned to you. This is why it is an O(N) operation with the size of the offset. This is true. The data is never returned to the client or anything, it's just that on the server the b-tree data structures are not augmented with the necessary information to do log(n) offset seeks so they have to scan. This is an orthogonal issue to all of the conflict stuff.
Dave_Rosenthal 8y ago
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 8y ago
  The example here: https://apple.github.io/foundationdb/developer-guide.html?highlight=conflict%20free#conflict-ranges https://apple.github.io/foundationdb/developer-guide.html?hi... 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.

ryanworl 8y ago

Range reads do create conflict ranges for the entire range even if you use offsets. Not only does it create the conflict range, I think it actually does the work of reading the data, it just isn’t returned to you. This is why it is an O(N) operation with the size of the offset. Not sure of the exact scenario you’re envisioning with atomic ops, but they’re essentially blind writes from what I understand. I don’t know how blind writes relate to transaction isolation, but I’m sure someone can fill in the details.

Dave_Rosenthal 8y ago
>Not only does it create the conflict range, I think it actually does the work of reading the data, it just isn’t returned to you. This is why it is an O(N) operation with the size of the offset. This is true. The data is never returned to the client or anything, it's just that on the server the b-tree data structures are not augmented with the necessary information to do log(n) offset seeks so they have to scan. This is an orthogonal issue to all of the conflict stuff.

Dave_Rosenthal 8y ago

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 8y ago
The example here: https://apple.github.io/foundationdb/developer-guide.html?highlight=conflict%20free#conflict-ranges https://apple.github.io/foundationdb/developer-guide.html?hi... 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.