Не понимаю, чего тут такую кашу развели с несчастным READ COMMITED - ведь написанно же, читаем закомиченные данные. Хотим второй раз те же данные считать, ставим REPEATABLEREAD, боимсе при повторном чтении новые записи схлопотать - ставим SERIALIZABLE. Все как написано в стандарте, работать в любом сервере должно одинаково по смыслу. Не понятно к чему здесь можно спорить ... а то вон Yo! вообще уже по индексам незакомиченные данные читать начал прямо на RC, кошмар да и только
--
www.rusug.ru - портал русскоязычной группы пользователей Sybase

ChA Anton DemidovА если добавить "блокирующая", то будет понятнее?
Получится "блокирующая читающая транзакция" (та, что не даст в MSSQL другой транзакции обновить эти же строки)Если не вдаваясь в определения, коим полон Инет, то для меня транзакция - это последовательность изменений БД из одного целостного состояния в другое. Соответственно, чтение, само по себе, транзакцией не считается. В блокировочниках, как правило, при любом чтении используемые данные блокируются, за исключением разве, особых условий, когда это не делается, наподобие упомянутых здесь ранее. Отсюда, нет необходимости изобретать эвфемизмов типа "читающая транзакция". Так что, возможно, надо было быть проще и прямо так и писать "блокирующее чтение", так как к транзакциям в прямом("классическом") смысле эта процедура никакого отношения не имеет, IMHO.
Мне кажется, что для того чтобы произвести целостное состояние из одного в другое в первую очередь требуется чтение данных, а уж потом их изменение (даже на вставку таблиц с FK будут читаться родительские таблицы). Соответственно чтение должно обеспечить доступ к целостной информации, а значит так же включается в понятие транзакции. По стандарту допустимое качество целостности информации определяется уровнями изоляции, на практической реализации это разруливается shared-блокировками или работой с версиями записей для различных СУБД. Хотя конечно вопрос спорный.

Еще хотелось бы задать немного ламерский вопрос тем, кто работает с версионниками (так сказать для ликбеза) - как на версионнике обеспечить уровень изоляции SERIALIZABLE для гарантированного отсутствия фантомов.
К примеру мне нужно по условию задачи вставить в Таблицу1 запись и если это первая вставленная запись, то вставить запись в Таблицу2. Никаких уникальных индексов/ограничений на обеих таблицах нет. Для блокировочника даже на уровне RC этот вариант замечательно отработает. Что нужно сделать на версионнике, чтобы 2 сессии при одновременной вставке первой записи в Таблицу1 получили на выходе только 1 запись в Таблице2 ? (естественно без блокировки таблицы в эклюзивном режиме).

Dimitry Sibiryakov
ASCRUS
Что нужно сделать на версионнике, чтобы 2 сессии при одновременной
вставке первой записи в Таблицу1 получили на выходе только 1 запись в
Таблице2 ? (естественно без блокировки таблицы в эклюзивном режиме).

Не нужно ничего делать ибо полный облом: в таблице2 будет две записи в
силу одного из базовых принципов транзакций (не помню, правда которого
из ACID. Кажется, I): каждая транзакция работает с базой так будто
других транзакций не существует. Если блокировочники позволяют нарушать
ACID, это... их ниша.
Posted via ActualForum NNTP Server 1.3
С чего это вдруг нарушение ACID у блокировочников я не очень понял. На блокировочнике и будет, что транзакции обе отработают согласованно, как будто обе работают в монопольном режиме и во второй таблице будет только одна запись.

andrey_anonymous Но-но, попрошу без провокаций :)
Согласованое изменение данных требует синхронизации, будь ты хоть десятирежды версионником.
С другой стороны, попробуйте приветси хоть одну реальную задачу, под которую требуется контроль количества записей в таблице и которую нельзя решить без такого контроля после небольшой нормализации :)
Что же до мнимых преимуществ блокировочников в плане соответствия стандарту - то я с удовольствием променяю это соответствие на возможность запустить отчет по оперативным OLTP-таблицам в разгар рабочего дня ;)
Это не провокация, а вопрос. Задача приведена упрощенная, однако реально существует определенный круг таких задач, тот же биллинг. Я тоже как бы запускаю отчеты по оперативным OLTP таблицам на блокировочнике в разгар рабочего дня и проблем не наблюдаю, так как есть функционал сервера, позволяющий решать проблему блокирования читателей с помощью тех же времянок. И меня интересует не стандарт, а именно фантомы в чистых версионниках - хочется понять насколько сейчас по сравнению с ними выгоднее гибриды (тот же MSSQL 2005 или ASA10), которые позволяют одновременно работать на блокировках с честным SERIALIZABLE для OLTP и через версии записей/страниц организовывать SNAPSHOP для OLAP.

P.S. Я так правильно понимаю у чистых версионников моя поставленная проблема должна решается не сервером, а проектировщиком (как я решаю такую же проблему для OLAP на блокировочнике) ?