Ну, в Oracle или Postgres sequence гарантирует, что выдаёт строго возрастающие числа, в сколь угодно параллельных запросах. Оно вроде бы шага строго в 1 не гарантирует, он обычно обеспечивает.
В другом месте они приямо говорят: "Selecting the ORDER option ensures that each NEXTVAL request across the cluster will be synchronized so that usage is chronologically ordered. This is achieved by having all sessions share a single cache for this sequence. Each reference to NEXTVAL will involve a lock request to claim a new value".
Понятно, что для линеаризации в рамках одной сессии достаточно NOORDER и просто неповторяющихся чисел.
Да я не об этом. Если запросы параллельные, как можно говорить о "строго возрастающих" числах? Иными словами, время commit параллельных запросов не определяется "строго возрастающим" числом.
"Строго возрастающее" число определяет, какие транзакции вы будете обозревать. Если у вас два типа транзакций - одни читают X и модифицируют Y, другие дописывают новые строки в X, в ACID нет ничего, что бы заставляло транзакции первого типа обозревать какие-либо изменения в X вообще.
no subject
Про CAP и ACID согласен, погорячился.
no subject
на самом деле sequence - это инструмент линеаризации обозреваемости committed транзакций.
no subject
В другом месте они приямо говорят: "Selecting the ORDER option ensures that each NEXTVAL request across the cluster will be synchronized so that usage is chronologically ordered. This is achieved by having all sessions share a single cache for this sequence. Each reference to NEXTVAL will involve a lock request to claim a new value".
Понятно, что для линеаризации в рамках одной сессии достаточно NOORDER и просто неповторяющихся чисел.
no subject
"Строго возрастающее" число определяет, какие транзакции вы будете обозревать. Если у вас два типа транзакций - одни читают X и модифицируют Y, другие дописывают новые строки в X, в ACID нет ничего, что бы заставляло транзакции первого типа обозревать какие-либо изменения в X вообще.
no subject