nine_k: A stream of colors expanding from brain (Default)

[personal profile] nine_k 2012-04-13 09:19 am (UTC)(link)
Ну, в Oracle или Postgres sequence гарантирует, что выдаёт строго возрастающие числа, в сколь угодно параллельных запросах. Оно вроде бы шага строго в 1 не гарантирует, он обычно обеспечивает.

Про CAP и ACID согласен, погорячился.

[identity profile] sassa-nf.livejournal.com 2012-04-13 02:46 pm (UTC)(link)
оппа, как это - строго возрастающие числа в параллельных запросах? ;-)

на самом деле sequence - это инструмент линеаризации обозреваемости committed транзакций.
nine_k: A stream of colors expanding from brain (Default)

[personal profile] nine_k 2012-04-14 09:19 am (UTC)(link)
Как — понятно: отдельный синхронный механизм (опционально). У оракла, по кр. мере.

Specify ORDER to guarantee that sequence numbers are generated in order of request. This clause is useful if you are using the sequence numbers as timestamps. Guaranteeing order is usually not important for sequences used to generate primary keys.

ORDER is necessary only to guarantee ordered generation if you are using Oracle Database with Real Application Clusters. If you are using exclusive mode, sequence numbers are always generated in order.


В другом месте они приямо говорят: "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 и просто неповторяющихся чисел.

[identity profile] sassa-nf.livejournal.com 2012-04-15 08:22 am (UTC)(link)
Да я не об этом. Если запросы параллельные, как можно говорить о "строго возрастающих" числах? Иными словами, время commit параллельных запросов не определяется "строго возрастающим" числом.

"Строго возрастающее" число определяет, какие транзакции вы будете обозревать. Если у вас два типа транзакций - одни читают X и модифицируют Y, другие дописывают новые строки в X, в ACID нет ничего, что бы заставляло транзакции первого типа обозревать какие-либо изменения в X вообще.

[identity profile] sassa-nf.livejournal.com 2012-04-15 08:38 am (UTC)(link)
и второе. "строго возрастающее" число может не обозреваться таким, ибо не все транзакции commit - какие-то будут rollback.