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

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

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

на самом деле sequence - это инструмент линеаризации обозреваемости committed транзакций.

Date: 2012-04-14 09:19 am (UTC)
nine_k: A stream of colors expanding from brain (Default)
From: [personal profile] nine_k
Как — понятно: отдельный синхронный механизм (опционально). У оракла, по кр. мере.

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 и просто неповторяющихся чисел.

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

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

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

Profile

juan_gandhi: (Default)
Juan-Carlos Gandhi

June 2025

S M T W T F S
1 2345 6 7
8 9 10 11 121314
15161718 1920 21
222324252627 28
29 30     

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 2nd, 2025 01:50 pm
Powered by Dreamwidth Studios