Здравствуйте. Возможно у меня дурацкий вопрос.
Есть два клиента, оба одновременно правят одну и туже запись.
Действия клиента.
1. Читаем данные из бд
2. Кешируем их
3. Пользователь редактирует данные в кеше.
4. Открываем транзакцию, пишем в бд, закрываем транзакцию
Вот теперь вопрос, при записи данных 1 клиентом в бд, 2 клиент, не записавший еще
их в бд имеет у себя в кеше недостоверные данные. Как при записи данных 2 клиентом проверить, не внес ли кто до него
изменения? И в этом случае не дать выполнить изменения ?
Держать открытой транзакцию на все время жизни форма(диалога) — имхо не верно.
Проверять ручками на верность записей — вроде тоже маразм. Как это решается правильно?
блокирование на уровне приложения — два поля, кто и восколько "заблокировал", если клиент умер/ушел в запой — решается на уровне приложения ... в веб приложениях (когда каждый раз другая сесия) другого варианта и нет.
Здравствуйте, <Аноним>, Вы писали: А>Вот теперь вопрос, при записи данных 1 клиентом в бд, 2 клиент, не записавший еще А>их в бд имеет у себя в кеше недостоверные данные. Как при записи данных 2 клиентом проверить, не внес ли кто до него А>изменения? И в этом случае не дать выполнить изменения ? А>Держать открытой транзакцию на все время жизни форма(диалога) — имхо не верно. А>Проверять ручками на верность записей — вроде тоже маразм. Как это решается правильно?
Спасибо огромное, Sinclair, Merle.
Инфы много, перевариваю. Совсем уж хамство, но как задать lock на таблицу (ы)
средствами TSQL в SQL Server? Еще интересно, лок сохраняется внутри конкретной транзакции
или до тех пор пока не снимешь? Еще раз прошу прощения, понимаю в BOL это все дожно быть,
просто голова кипит — перевариваю.
Здравствуйте, <Аноним>, Вы писали: А>Спасибо огромное, Sinclair, Merle. А>Инфы много, перевариваю. Совсем уж хамство, но как задать lock на таблицу (ы) А>средствами TSQL в SQL Server? Еще интересно, лок сохраняется внутри конкретной транзакции А>или до тех пор пока не снимешь? Еще раз прошу прощения, понимаю в BOL это все дожно быть, А>просто голова кипит — перевариваю. Блокировки в MS SQL Server
читал?
Спасибо за ссылку,но вот в чем дело, блокировки-то действуют в рамках транзакции, то есть для этого нужно всю форму(диалог) при загрузке держать в транзакции. А это выходит длинная транзакция, пока там пользователь будет пить чай, транзакция будет висеть(ну допустим ограничение по времени жизни как-то сделать). А этого мне не хотелось бы. Остается вариант 2? Самому как-то определять изменения данных? Есть ли еще варианты? Или я что-то не так понял?
Re[2]: транзакции, блокировки?
От:
Аноним
Дата:
19.02.04 13:16
Оценка:
Здравствуйте, Аноним, Вы писали:
А>блокирование на уровне приложения — два поля, кто и восколько "заблокировал", если клиент умер/ушел в запой — решается на уровне приложения ... в веб приложениях (когда каждый раз другая сесия) другого варианта и нет.
Спасиб, просто я думал, что должны быть более элегантные решения...Но пока не нахожу их.
Здравствуйте, Merle, Вы писали:
А>> Или я что-то не так понял? M>см. "пользовательские блокировки" sp_addlock, sp_releaselock.
Тьфу, sp_GetAppLock, sp_ReleaseAppLock, совсем плохой стал. Скорее всего их функциональности хватит за глаза. Прежде чем реализовывать что-то свое, надо максимально использовать возможности сервера.
читал? А>Спасибо за ссылку,но вот в чем дело, блокировки-то действуют в рамках транзакции, то есть для этого нужно всю форму(диалог) при загрузке держать в транзакции. А это выходит длинная транзакция, пока там пользователь будет пить чай, транзакция будет висеть(ну допустим ограничение по времени жизни как-то сделать). А этого мне не хотелось бы. Остается вариант 2? Самому как-то определять изменения данных? Есть ли еще варианты? Или я что-то не так понял?
Ты по-моему чего-то недочитал.
1. Длинные транзакции считаются злом. В принципе, можно пользоваться и ими, принимая во внимание следующие вещи:
а) все доступы к данным надо аккуратно снабжать соответствующими хинтами, чтобы получить требуемую блокировку. Например, нажали кнопочку Edit — select with (updlock).
б) таймауты по умолчанию стоят в бесконечность. Чтобы корректно обнаруживать залоканность чего бы то ни было, надо их ставить в конечные значения
в) в любом случае время жизни таких блокировок ограничено временем жизни транзакции, т.е. при дедлоке (от неаккуратности) или при рестарте приложения/потере соединения с сервером блокировки исчезнут.
2. Можно сделать самопальные персистентные блокировки, как я описал здесь
. Они выживают отключение приложения, и позволяют сохранять на сервере промежуточные результаты. Кроме того, они по природе своей не требуют постоянного подключения и открытой транзакции — можно подконнектиться, забрать документ, отключиться, поработать, а потом снова подключиться и отдать результат.
Трудоемкость в обоих случаях примерно одинаковая.(имхо).
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Аноним, Вы писали:
А>Есть ли еще варианты?
Сделать именно так, как ты хотел в первоначальном сообщении, можно с помощю типа rowversion (aka timestamp).
Поле этого типа автоматически меняется при изменении любого другого поля в записи. Таким образом, запомнив предыдущее значение, можно отследить факт изменения записи.
С помощью такого механизма оптимистические блокировки реализуются элементарно, но боюсь это немного не то, что тебе нужно.
Мы уже победили, просто это еще не так заметно...
Re[7]: транзакции, блокировки?
От:
Аноним
Дата:
19.02.04 14:00
Оценка:
Здравствуйте, Sinclair, Вы писали:
S>Ты по-моему чего-то недочитал.
Точнее перечитал. S>1. Длинные транзакции считаются злом. В принципе, можно пользоваться и ими, принимая во внимание следующие вещи: S>а) все доступы к данным надо аккуратно снабжать соответствующими хинтами, чтобы получить требуемую блокировку. Например, нажали кнопочку Edit — select with (updlock). S>б) таймауты по умолчанию стоят в бесконечность. Чтобы корректно обнаруживать залоканность чего бы то ни было, надо их ставить в конечные значения S>в) в любом случае время жизни таких блокировок ограничено временем жизни транзакции, т.е. при дедлоке (от неаккуратности) или при рестарте приложения/потере соединения с сервером блокировки исчезнут.
Спасибо, в общем мне надо не много изменить свой подход. Придется все же создавать транзакцию при начале редактирования, но со всеми необходимыми условиями и убивать ее только после выхода из формы.
Видимо без этого никак.
S>2. Можно сделать самопальные персистентные блокировки, как я описал здесь
.
Да весьма интересный подход. Но я все же предпочту чтобы за блокировкой следил делал сервер.
В моем случае, проще изменить под первый подход.
Огромное спасибо.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Merle, Вы писали:
А>>> Или я что-то не так понял? M>>см. "пользовательские блокировки" sp_addlock, sp_releaselock.
M>Тьфу, sp_GetAppLock, sp_ReleaseAppLock, совсем плохой стал. Скорее всего их функциональности хватит за глаза. Прежде чем реализовывать что-то свое, надо максимально использовать возможности сервера.
Спасибо большое за ответ, но вообше-то эта штука для пользовательских ресурсов,то есть форм и проч, хотелось бы все же на объекты бд блокировки делать.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Аноним, Вы писали:
А>>Есть ли еще варианты? M>Сделать именно так, как ты хотел в первоначальном сообщении, можно с помощю типа rowversion (aka timestamp).
M>Поле этого типа автоматически меняется при изменении любого другого поля в записи. Таким образом, запомнив предыдущее значение, можно отследить факт изменения записи. M>С помощью такого механизма оптимистические блокировки реализуются элементарно, но боюсь это немного не то, что тебе нужно.
Да, спасибо, я тоже обдумывал этот вариант, но пока отставил его как вариант, не "серверный", так скажем.
Здравствуйте, Аноним, Вы писали:
А>Спасибо большое за ответ, но вообше-то эта штука для пользовательских ресурсов,то есть форм и проч, хотелось бы все же на объекты бд блокировки делать.
Зачем?
В данном случае (при редактировании формы пользователем) нужна именно блокировка некоего абстрактного объекта типа "документ". Нет никакого смысла привязываться к конкретным записям конкретной таблицы, это лишь добавит головной боли и не даст никакой выгоды.
Мы уже победили, просто это еще не так заметно...
Re[9]: транзакции, блокировки?
От:
Аноним
Дата:
19.02.04 14:13
Оценка:
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Аноним, Вы писали:
А>> Придется все же создавать транзакцию при начале редактирования, но со всеми необходимыми условиями и убивать M>Не связывайся с этим, горя хлебнешь... M>Пользовательские блокировки вполне держатся не на время транзакции, а на время сессии, если мне память не изменяет.
Эх!. Я уже и так хлебаю от души. Тут некоторые вопросы с названием ресурсов, на которые делается лок, откуда эти названия берутся, точнее как их определить, по имени в ресурсах что-ли, пока ничего не в голову не лезет. Попробую оба варианта или и тот и другой))
.
других нету, или сервер или кривые ручки ...
с сервером основные "плюсы" ты я так понял выяснил, но учти что может появится вариант с вебом/апп сервером который ходит с одним логином, да и умершие сессии не всегда отваливаются по таймауту. Короче это нормальный способ, который юзаются во многих серьезных решениях.
Здравствуйте, <Аноним>, Вы писали:
M>>Пользовательские блокировки вполне держатся не на время транзакции, а на время сессии, если мне память не изменяет. А>Тут некоторые вопросы с названием ресурсов, на которые делается лок, откуда эти названия берутся, точнее как их определить, по имени в ресурсах что-ли, пока ничего не в голову не лезет.
Я для именования ресурса в sp_getapplock склеиваю имя таблицы с значением первичного ключа. Т.е. открывает пользователь форму для редактирования заказа с PK = 123 — лочится ресурс "orders123". Имхо, sp_getapplock/sp_releaseapplock — как раз то, что тебе нужно...
1) не дать поменять второму открывшему (смотри в сторону блокировок)
2) или проверить, что кто-то что-то поменял в записи, пока читали и думали, перед сохранением?
используй (например в MS SQL Server 2000) тип поля timestamp.
примерно так:
считал .... стичай и поле timestamp
отредактировал в 'кеше' ...
хочешь сохранить — заблокируй запись на изменение ...
считай ЕЩЁ раз поле timestamp и сравни с сохранённым в 'кеше',
если одинаково
сохраняй
иначе (сервер БД сам поменяет значение поля, если кто-то меняет запись)
уведомляй пользователя о том, что кто-то уже что-то поменял и далее по логике, например
считывай новые значения на редактирование в 'кеш'
... << RSDN@Home 1.1.0 stable >>
Re[2]: транзакции, блокировки?
От:
Аноним
Дата:
20.02.04 07:10
Оценка:
Здравствуйте, KGP, Вы писали:
KGP>Здравствуйте, <Аноним>, Вы писали:
KGP>2) или проверить, что кто-то что-то поменял в записи, пока читали и думали, перед сохранением? KGP>используй (например в MS SQL Server 2000) тип поля timestamp.
Спасибо, я правда думаю использовать поле GUID для этих целей, правда при обновлении нескольких таблиц есть некоторые сложности, но имхо это разрешается логикой поведения.
Есть встречный вопрос, как узнать, заблокирован ли какой-либо ресурс? Есть sp_lock, но там нужен id процесса, но его получить в клиенте? И еще, есть ли способ задать время жизни конкрентой транзакции средствами TSQL?
Еще раз спасибо всем, кто ответил.
Здравствуйте, Аноним, Вы писали:
А>Есть встречный вопрос, как узнать, заблокирован ли какой-либо ресурс? Есть sp_lock, но там нужен id процесса, но его получить в клиенте? А>И еще, есть ли способ задать время жизни конкрентой транзакции средствами TSQL?
Ты явно идешь неправильным путем... Я очередной раз хочу посоветовать тебе посмотреть в сторону пользовательских блокировок, они как раз для таких случаев и придумывались.
Вся информация о блокировках строк в таблице — системная и использовать ее можно только для отладки.
Во-первых никто, никогда не гарантировал ее согласованности, во вторых подобное решение будет полностью немасштабируемо и совершенно не факт, что заработает даже не аналогичной системе.
Для того чтобы использовать внутренний менеджер блокировок сиквела в своих целях, существуют пользовательские блокировки, они предоставляют весь необходимый функционал.
Лезть для этого в системные таблички нет никакой необходимости.
Мы уже победили, просто это еще не так заметно...
Re[4]: транзакции, блокировки?
От:
Аноним
Дата:
20.02.04 08:27
Оценка:
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Аноним, Вы писали:
M>Ты явно идешь неправильным путем... Я очередной раз хочу посоветовать тебе посмотреть в сторону пользовательских блокировок, они как раз для таких случаев и придумывались.
Да, вообще-то не иду таким путем, который вытекает из моего вопроса. Мне просто интересно до конца докопать вопрос. Лезть в менеджер блокировок, согласен не стоит. А пользовательские блокировки — действительно интересная вещь, спасибо за подсказку.
Здравствуйте, <Аноним>, Вы писали:
KGP>>Здравствуйте, <Аноним>, Вы писали:
А>Спасибо, я правда думаю использовать поле GUID для этих целей, правда при обновлении нескольких таблиц есть некоторые сложности, но имхо это разрешается логикой поведения.
1) Я не понимаю зачем тебе GUID, тебе ведь не уникальность нужна а check на изменение записи. А>Есть встречный вопрос, как узнать, заблокирован ли какой-либо ресурс? Есть sp_lock, но там нужен id процесса, но его получить в клиенте? И еще, есть ли способ задать время жизни конкрентой транзакции средствами TSQL?
2) Я совершенно согласен с Merle что на такие манёвры, как sp_lock, лучше не идти.
Узнать заблокирован ли ресурс ... зачем, если для того, чтоб заблокировать — бери и блокируй, не получится — значит он уже заблокирован.
Предлагаю 'время жизни транзакции' определять именно пользовательские блокировки
А у пользователя на форме изменения ставишь таймер и либо тот САМ продлевает (он 'типа' думает), либо пересчитывать данные и запрос — а ещё разок заблокируем эту запись и как тока ДА — пересчитать данные и опять пользовательские блокировки плюс таймер ...
Здравствуйте, Аноним, Вы писали:
А> Мне просто интересно до конца докопать вопрос.
Ну что ж, похвальное желание...
Для копания дальше поможет тщательное изучение системных таблиц (они есть в документации) и системных хранимых процедур, благо их текст доступен.
Да и у Алекса в статье, кажется тоже системные таблички были упомянуты.
В частности для блокировок я уже давно, и с удовольствием пользую вот такой, слега модифицированый запрос выдранный из sp_lock:
select
convert (smallint, req_spid) As spid,
rsc_dbid As dbid,
rsc_objid As ObjId,
so.name as ObjName,
rsc_indid As IndId,
substring (v.name, 1, 4) As Type,
substring (rsc_text, 1, 16) as Resource,
substring (u.name, 1, 8) As Mode,
substring (x.name, 1, 5) As Status
from master.dbo.syslockinfo sl
INNER JOIN master.dbo.spt_values v ON sl.rsc_type = v.number
INNER JOIN master.dbo.spt_values x ON sl.req_status = x.number
INNER JOIN master.dbo.spt_values u ON sl.req_mode + 1 = u.number
LEFT JOIN sysobjects so ON sl.rsc_objid = so.ID
where v.type = 'LR' and x.type = 'LS' and u.type = 'L' and so.Name =
'<имя таблицы>'
order by spid, Type, Resource
Который показывает всю нужную мне информацию о блокировках, которые наложены на таблицу с заданым именем.
Мы уже победили, просто это еще не так заметно...
Re[4]: транзакции, блокировки?
От:
Аноним
Дата:
20.02.04 09:05
Оценка:
Здравствуйте, KGP, Вы писали:
KGP>Здравствуйте, <Аноним>, Вы писали:
KGP>>>Здравствуйте, <Аноним>, Вы писали:
А>>Спасибо, я правда думаю использовать поле GUID для этих целей, правда при обновлении нескольких таблиц есть некоторые сложности, но имхо это разрешается логикой поведения. KGP>1) Я не понимаю зачем тебе GUID, тебе ведь не уникальность нужна а check на изменение записи.
Вот с помощью GUID можно сделать небольшую проверку на изменение записи. Просто менять значение GUID
при Update.
А>>Есть встречный вопрос, как узнать, заблокирован ли какой-либо ресурс? Есть sp_lock, но там нужен id процесса, но его получить в клиенте? И еще, есть ли способ задать время жизни конкрентой транзакции средствами TSQL?
KGP>А у пользователя на форме изменения ставишь таймер и либо тот САМ продлевает (он 'типа' думает), либо пересчитывать данные и запрос — а ещё разок заблокируем эту запись и как тока ДА — пересчитать данные и опять пользовательские блокировки плюс таймер ...
Да это ясно, интересно, есть ли в сервере такая возможность, собственно весь вопрос интересует именно с точки зрения _сервера_ и TSQL.
Спасибо за ответ.
Здравствуйте, <Аноним>, Вы писали:
А>Вот с помощью GUID можно сделать небольшую проверку на изменение записи. Просто менять значение GUID А>при Update.
Самому менять GUID?
timestamp сервер поменяет при update.
... << RSDN@Home 1.1.0 stable >>
Re[6]: транзакции, блокировки?
От:
Аноним
Дата:
20.02.04 10:05
Оценка:
Здравствуйте, KGP, Вы писали:
KGP>Здравствуйте, <Аноним>, Вы писали:
А>>Вот с помощью GUID можно сделать небольшую проверку на изменение записи. Просто менять значение GUID А>>при Update. KGP>Самому менять GUID? KGP>timestamp сервер поменяет при update.
Угу, я уже прочитал. Просто в рамках моей задачи возможно совместить GUID еще с одной задачей
если используешь адо.нет — то там эти вопросы решаются легко с помощью параллелизма
... << RSDN@Home 1.1.0 stable >>
Re[7]: транзакции, блокировки?
От:
Аноним
Дата:
24.02.04 14:18
Оценка:
Здравствуйте все!
Я конечно извиняюсь, может не внимательно читал BOL и что-то не понял, но как установить хинт (updlock) или еще как блокирнуть (без пользовательских блокировок) на записи возвращаемые след. запросом
SELECT * from [X] LEFT JOIN [Y] on .... where....
Точнее, как я понял его вообще не установишь на такой запрос, что вроде как разумно и так и должно быть. Но как быть в таком случае?
Здравствуйте, Аноним, Вы писали:
А>Точнее, как я понял его вообще не установишь на такой запрос, что вроде как разумно и так и должно быть. Но как быть в таком случае?
Вообще установить можно, если надо и на таблицу X и на таблицу Y, то примерно так:
SELECT * from [X] WITH(UPDLOCK)LEFT JOIN [Y] WITH(UPDLOCK)on .... where....
Можно попытаться дописать WITH(UPDLOCK, ROWLOCK), но все равно, гарантии, что заблокируется только одна строка — никто не даст.
Подробности вот здесь: http://www.rsdn.ru/?article/?451
Здравствуйте, Merle, Вы писали:
M>SELECT * from [X] WITH(UPDLOCK) LEFT JOIN [Y] WITH(UPDLOCK) on .... where.... M>[/sql]
Упппссс! Совсем я заработался Спасибо, просто я что-то не так писал, для обычного select все нормально проходило, а в JOIN QA меня посылал. Полез в BOL — там еще больше пурги...
M>Подробности вот здесь: http://www.rsdn.ru/?article/?451
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте. Возможно у меня дурацкий вопрос. А>Есть два клиента, оба одновременно правят одну и туже запись. А>Действия клиента. А>1. Читаем данные из бд А>2. Кешируем их А>3. Пользователь редактирует данные в кеше. А>4. Открываем транзакцию, пишем в бд, закрываем транзакцию
А>Вот теперь вопрос, при записи данных 1 клиентом в бд, 2 клиент, не записавший еще А>их в бд имеет у себя в кеше недостоверные данные. Как при записи данных 2 клиентом проверить, не внес ли кто до него А>изменения? И в этом случае не дать выполнить изменения ? А>Держать открытой транзакцию на все время жизни форма(диалога) — имхо не верно. А>Проверять ручками на верность записей — вроде тоже маразм. Как это решается правильно?
К сожалению, не могу похвастаться высоким уровнем знаний и практическим применением оных. Но подобные вопросы подробно рассматривались в книге Тома Кайта "Oracle для профессионалов". Рекомендую посмотреть там. Конечно, книга посвещена Oracle. Так, что ответ скорее профильный.
Re[2]: транзакции, блокировки?
От:
Аноним
Дата:
25.02.04 16:11
Оценка:
A_T>К сожалению, не могу похвастаться высоким уровнем знаний и практическим применением оных. Но подобные вопросы подробно рассматривались в книге Тома Кайта "Oracle для профессионалов". Рекомендую посмотреть там. Конечно, книга посвещена Oracle. Так, что ответ скорее профильный.
что для версионика хорошо — блокировочнику смерть.
Здравствуйте, Alice_The_Fox, Вы писали:
A_T> Но подобные вопросы подробно рассматривались в книге Тома Кайта "Oracle для профессионалов".
Если мне не изменяет память, то у Тома Кайта про это только полторы страницы довольно невнятного текста, в то время как про это дело можно многотомник написать.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Alice_The_Fox, Вы писали:
A_T>> Но подобные вопросы подробно рассматривались в книге Тома Кайта "Oracle для профессионалов". M>Если мне не изменяет память, то у Тома Кайта про это только полторы страницы довольно невнятного текста, в то время как про это дело можно многотомник написать.
Там больше ДАЖЕ 2 страниц — фактически, этому посвящена как минимум одна глава (правда с легкими лирическими отклонениями от темы )
Здравствуйте, Alice_The_Fox, Вы писали:
A_T>Там больше ДАЖЕ 2 страниц — фактически, этому посвящена как минимум одна глава (правда с легкими лирическими отклонениями от темы )
Ну да, глава из полутора страниц, посвященная лирическим отсуплениям...
Вообщем, если не собираешься делать это под Оракл, то ориентироваться на Тома Кайта не стоит, он конечно хороший дядька, но мы его любим за другое...
Мы уже победили, просто это еще не так заметно...
)) 
а check на изменение записи.
