Здравствуйте. Возможно у меня дурацкий вопрос.
Есть два клиента, оба одновременно правят одну и туже запись.
Действия клиента.
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>Пользовательские блокировки вполне держатся не на время транзакции, а на время сессии, если мне память не изменяет.
Эх!. Я уже и так хлебаю от души. Тут некоторые вопросы с названием ресурсов, на которые делается лок, откуда эти названия берутся, точнее как их определить, по имени в ресурсах что-ли, пока ничего не в голову не лезет. Попробую оба варианта или и тот и другой))
.
других нету, или сервер или кривые ручки ...
с сервером основные "плюсы" ты я так понял выяснил, но учти что может появится вариант с вебом/апп сервером который ходит с одним логином, да и умершие сессии не всегда отваливаются по таймауту. Короче это нормальный способ, который юзаются во многих серьезных решениях.
Мы уже победили, просто это еще не так заметно...
)) 