Резко встала необходимость соорудить свой генератор Id'шек. Создана таблица
Ну... А далее все просто:
стартуется транзакция
генериться Id
записываются данные с новорожденным Id
commit
И тут уже пару раз вылезло, что на один и тот же Id повесилось несколько разных данных Ж8-/ Скорее всего это произошло из-за того, что уровень изоляции транзакции
select @@isolation
1

Transact-SQL User’s Guide
Уровень 1 - Здесь предполагается, что в каждой транзакции считываются фактические данные, а не данные, записанные не окончившейся транзакцией. Другими словами, здесь не допускается считывание неподтвержденных данных. Этот уровень изоляции устанавливается по умолчанию SQL Сервером

т.е. это READ_COMMITED. Выходит кто-то успел до commita транзакции в одном коннекте, считать данные в другом. А поскольку транзакция в первом коннекте еще не за'commit'чена, то и значение получено аналогичное. Отсюда вылезает, что надо блокировать таблицу, а еще лучше запись, а самый лучший вариант (если возможно) - поле.
Поскольку субася - блокировочник, то, я так понимаю, при старте транзакции происходит блокирование. Только вот как и где можно указать что я хочу заблокировать: таблицу, запись, поле?

select @@version
Adaptive Server Enterprise/12.5.1/EBF 11428/P/NT (IX86)/OS 4.0/ase1251/1823/32-bit/OPT/Wed Sep 17 11:10:54 2003

_________________
"Helo, word!" - 17 errors 56 warnings

а в середине куча проверок - ежели чего - rollback
_________________
"Helo, word!" - 17 errors 56 warnings

Да я, вообще-то, всю жизнь просидел на IB/FB, а это - версионники. И для меня любое понятие вне контекста транзакции - нонсенс. А тут проект возник на субасе. Времени толком разбираться - нЭт Вот и разбираюсь в ньюансах субаси и, соответственно, блокировочника - от случая к случаю... Как правило - когда вылазят грабли... Из сказанного понял, что блокировку ставит не begin transaction, а следующий за ней update... Т.е.: если даже одновременно стартовали две транзакции, то выполнившая первой update и заблокирует?
MasterZivОт чтения тоже.Гы... Кто бы мог подумать... А я думал что если уровень изоляции READ_COMMITED, то другие транзакции, 4 example, как в IB/FB, читать могут...
MasterZivИзоляция транзакции тут ни при чем.В свете выше сказанного (что блокировка ставиться и на чтение) теперь это понятно... BTW, а можно ли тогда сделать, чтобы блокировалась только запись, а чтение было возможным?
MasterZivБлокируется либо страница, либо запись, в зависимости от схемы блокировки твоей ключевой таблицы (IDS). Я бы кстати рекомендовал иметь ее на DOL , конкретно - на DRL.А где и как можно указать схему блокировки таблицы и что такое DOL и DRL?
_________________
"Helo, word!" - 17 errors 56 warnings

Александр ГoлдунНапример генераторы...Совершенно справедливо. На то они и генераторы. Просто речь, как все поняли, шла именно в общем контексте версионной СУБД.
Александр ГoлдунИ, кстати, разве в FB не так в ситуации, когда две
транзакции пытаются апдейтить одну и ту же запись?Если очень интересно - Транзакции, архитектура IB
Александр ГoлдунА что они смогут читать, если старое значение уже изменено на новое, но оно еще не commited?Речь шла не о том, что (какие данные) они могут считать, а о том что они вообще могут читать.
Александр Гoлдунdirty read со всемы вытекающими последствиями.При чем тут уровень изоляции, когда MasterZivupdate этой твоей таблицы ключей и так блокирует твою запись до конца транзакции. От чтения тоже.
Александр ГoлдунИ, кстати, если не секрет, зачем понадобилось изобретать свой велосипед? Чем не устраивает identity в качестве генератора ID?Не секрет ЭстЪ, 4 example, договор, выступающий в виде своего рода контейнера. И ЭстЪ документы входящие в него, 4 example - полисы. Ессесно, нумерация должна быть в контексте договора и непрерывная. Вариант генерить номера внутренних документов на ходу известен, рассматривался и не удовлетворил. Вот в двух словах...
AndynСкорее всего потому что это попытка сэмулировать генератор.Абсолютно в дырочку И, исходя из быстрой и конструктивной реакции, - не я первый и, скорее всего, не я последний, занимающийся изобретением лисапета Тем более метод, который я использую, практически стал стандартом де-факто (просто иногда его ната немного обработать напильником в зависимости от особенностей СУБД)

P.S. 2Александр Гoлдун А че Вы так на меня накинулись? На Вас подействовало упоминание об IB/FB как красная тряпка? BTW, из всех постов в данном топике только у вашего КПД нулевой. Его преспокойненько без ущерба можно перенести в ПТ .
_________________
"Helo, word!" - 17 errors 56 warnings

MasterZivДА.А select заблокирует (если он будет после begin transaction, но перед DML(insert/update/delete))? Или это прерогатива только DML'я?
MasterZivТут фсе сирьёзна !!Страшно аж жуть!!!
MasterZivНо есть нюансы. Например - блокировка на уровне полей, т.е. по идее если ты читаешь неизмененное поле, тебе дадут.А как сие можно забалабенитЪ ? Так сказать для общего развтия и повышения вченности ...
Ex_SoftА где и как можно указать схему блокировки таблицы
refman2.pdf
create table ... lock {datarows | datapages | allpages }

Оно?
_________________
"Helo, word!" - 17 errors 56 warnings

Andynпри условии, что некритично иметь в каждой таблице значения ключа по порядку (типа 1,2,3 ...)Как раз критично ;) Согласитесь, если бы Вы получили договор в котором есть Полис N1, Полис N2, Полис N5, Полис N6, то Вы сразу бы забеспокоились на предмет наличия отсутствия Полис N3, Полис N4 ;)
gardenmanПолучается, что пока один юзер не доделал свою транзакцию другие - идут покурить?Получается так... Но там внутри пару операторов - так, что они даже забить косячек не успеют... Причем по совету MasterZiv пересоздал с lock datarows (потому как по TABLE_ID понятно, что в ней сидят аналогичные ID'шки и других таблиц) - шоб другим не мешать ;)
gardenmanА ты точно следишь за тем ГДЕ у тебя коммит/роллбак?В смысле?
Листинг уже замусолил до дыр... Все стоит на своих местах...
_________________
"Helo, word!" - 17 errors 56 warnings

Александр ГoлдунКак это при чем? При dirty read как раз можно будет спокойно прочитать значение, даже если еще на закоммичена транзакция.
Гм... Но если MasterZivupdate этой твоей таблицы ключей и так блокирует твою запись до конца транзакции. От чтения тоже. то какая разница какой уровень изоляции: dirty read, read commited, snapshot - никто все равно прочитать не может . По крайней мере, я выше указанное предложение трактовал для себя таким образом.
Александр ГoлдунЯ просто всегда пытаюсь подойти к проблеме с
чуть более глобальной стороны.Аналогично... Но бывают моменты (сам, иногда, грешу таким), когда, не зная всей постановки задачи (когда человек предоставляет только локальную проблему, а расписывать ему все глобально попросту нет времени, да и незачем), со строны кажеться, что человек "...хочет странного...". А всего-то, что необходимо человеку, так это попросту решить эту локальную проблему. И все... ;)


_________________
"Helo, word!" - 17 errors 56 warnings

Александр ГoлдунКак это при чем? При dirty read как раз можно будет спокойно прочитать значение, даже если еще на закоммичена транзакция.
На характер проверил:

SQL Advantage (Session 1)

SQL Advantage (Session 2)
и...
SQL Advantage (Session 2)
Executing...


и только после

SQL Advantage (Session 1)

SQL Advantage (Session 2)
TABLE_ID VALUE_ID TABLE_NAME
----------- -------------------- ----------
1 2 2

так что прочитать-таки действительно нельзя
_________________
"Helo, word!" - 17 errors 56 warnings

Dim2000Значит, это был не Dirty Read
gardenmanset transaction isolation level 0
Совершенно верно - прочиталось... Вот теперь у меня все устаканилось в гольове ;) Всем спасибо!
_________________
"Helo, word!" - 17 errors 56 warnings

MasterZivНипонил
MasterZivНо есть нюансы. Например - блокировка на уровне полей , т.е. по идее если ты читаешь неизмененное поле, тебе дадут.Как можно в субасе организовать блокировку на уровне полей? На пальцах, если можно и не в облом, обЪясните, pls...
_________________
"Helo, word!" - 17 errors 56 warnings