Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
softwarer
"Классический", надеюсь, не всегда синоним слова "тупой". Корректно проверить все старые значения полей обычно немного тяжеловато, ибо во-первых, из-за null-ов, сравнение получается громоздким, во-вторых, блобы обычно немного неудобно сравнивать на равенство, в-третьих, объёмы...


Если условие во where генерирует какой-то framework (или дельфийский компонент, или подобное; заодно оно может понимать, какие поля NOT NULL, и учесть это), то за громоздкость и объёмы можно не переживать, просто не смотря лишний раз на генерируемый код. Но решение с version я только в TOPLink'е видел. (Наверное, есть и в GLORP-е, наследнике TOPLink'а, но я не интересовался).
8 янв 12, 13:52    [11870007]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
optimistic concurrency
Guest
Victor Metelitsa
Классический вариант, который я видел "везде" - проверить все старые значения полей.


How to use the timestamp column of a table for optimistic concurrency control in SQL Server
8 янв 12, 15:56    [11870283]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Я правильно понимаю
Guest
Я правильно понимаю, что в крайних случаях:
- пессимистический подход ближе к блокировочникам, есть вероятность deadlock, но не возможен update conflict
- оптимистический подход ближе к версионникам, мало вероятен(в некоторых вариантах реализации не возможен) deadlock, но появляется вероятность update conflict


Вот тут уже выше давали ссылки:
http://atamanenko.blogspot.com/2009/04/blog-post_22.html
автор
Использование оптимистичных блокировок позволяет избежать взаимных блокировок (dead-lock).


Например в блокировочнике MS SQL про update conflict никто и не слышал.
https://www.sql.ru/forum/actualthread.aspx?tid=908235

А оптимистическая блокировка в MS SQL реализуется особыми плясками с timestamp как показали выше, т.е. по сути
optimistic concurrency
How to use the timestamp column of a table for optimistic concurrency control in SQL Server
8 янв 12, 16:09    [11870309]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
optimistic concurrency
Victor Metelitsa
Классический вариант, который я видел "везде" - проверить все старые значения полей.


How to use the timestamp column of a table for optimistic concurrency control in SQL Server

Ну, я и не вездесущ.
8 янв 12, 16:13    [11870316]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54813

Я правильно понимаю
в блокировочнике MS SQL про update conflict никто и не слышал

Там у них про транзакции вообще слышал далеко не каждый второй.

Posted via ActualForum NNTP Server 1.5

8 янв 12, 16:16    [11870321]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Я правильно понимаю
Я правильно понимаю, что в крайних случаях:
- пессимистический подход ближе к блокировочникам, есть вероятность deadlock, но не возможен update conflict
- оптимистический подход ближе к версионникам, мало вероятен(в некоторых вариантах реализации не возможен) deadlock, но появляется вероятность update conflict


"Оптимистичность" - в голове у разработчика, который создаёт приложение.

Оптимистичный подход (наверняка нам никто не помешает) должен быть примерно одинаков и там, и там, поскольку (по возможности) избегаются блокировки. Пессимистический (нам кто-то может помешать, и мы должны это предотвратить) же требует блокировок, а потому здесь возникают нюансы.
8 янв 12, 16:33    [11870350]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
неправильно понимаешь
Guest
Я правильно понимаю
Например в блокировочнике MS SQL про update conflict никто и не слышал.


MS SQL уже давно не только блокировочник.
8 янв 12, 16:34    [11870356]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Я правильно понимаю
Guest
неправильно понимаешь
Я правильно понимаю
Например в блокировочнике MS SQL про update conflict никто и не слышал.


MS SQL уже давно не только блокировочник.

Написано же "в блокировочнике MS SQL" - это не характеристика СУБД, а уточнение, что имеется ввиду его "блокировочная" часть.

Чукча не читатель?
Update Conflict в MS SQL
Подскажите, а возможен ли вообще в блокировочнике Update Conflict и в частности в MS SQL без использования MVC(ReadCommited/Snapshot)?
Интересует именно тот Update Conflict который связан с конкурирующими транзакциями, а не с FK или репликацией.
Навеяно:
Отличие пессимистической и оптимистической стратегии

Так что кончай тролить, по делу есть что сказать?

Dimitry Sibiryakov
Я правильно понимаю
в блокировочнике MS SQL про update conflict никто и не слышал

Там у них про транзакции вообще слышал далеко не каждый второй.

Т.е. ты утверждаешь что в MS SQL без использования MVC(ReadCommited/Snapshot) можно получить ошибку update conflict который связан с конкурирующими транзакциями, а не с FK или репликацией?
8 янв 12, 17:12    [11870415]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Я правильно понимаю
Guest
Victor Metelitsa
Я правильно понимаю
Я правильно понимаю, что в крайних случаях:
- пессимистический подход ближе к блокировочникам, есть вероятность deadlock, но не возможен update conflict
- оптимистический подход ближе к версионникам, мало вероятен(в некоторых вариантах реализации не возможен) deadlock, но появляется вероятность update conflict


"Оптимистичность" - в голове у разработчика, который создаёт приложение.

Оптимистичный подход (наверняка нам никто не помешает) должен быть примерно одинаков и там, и там, поскольку (по возможности) избегаются блокировки. Пессимистический (нам кто-то может помешать, и мы должны это предотвратить) же требует блокировок, а потому здесь возникают нюансы.

Безусловно нам никто ничего не мешает. Можно и в версионнике много чего блокировать и в блокировочнике хранить версии записей и много чего ещё неестественного накрутить. Но интересует их профильное использование.

У кого-нибудь есть ответ, уточнения или конструктивная критика такого обобщения?
8 янв 12, 17:18    [11870425]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54813

Я правильно понимаю
ты утверждаешь что в MS SQL без использования MVC...

....есть только один уровень изоляции транзакций - Dirty Read, вследствие чего работающие с
ним люди вообще о транзакциях не думают. И таки да, на этом уровне эту ошибку получить нельзя.

Posted via ActualForum NNTP Server 1.5

8 янв 12, 18:13    [11870551]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
ты единственный странный
Guest
Dimitry Sibiryakov
Я правильно понимаю
ты утверждаешь что в MS SQL без использования MVC...

....есть только один уровень изоляции транзакций - Dirty Read, вследствие чего работающие с
ним люди вообще о транзакциях не думают. И таки да, на этом уровне эту ошибку получить нельзя.

По моему ты единственный кто пользуется Dirty Read...
8 янв 12, 18:24    [11870598]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
NOLOCK MS SQL
Guest
Dimitry Sibiryakov
Я правильно понимаю
ты утверждаешь что в MS SQL без использования MVC...

....есть только один уровень изоляции транзакций - Dirty Read, вследствие чего работающие с
ним люди вообще о транзакциях не думают.


Дмитрий сегодня превзошел сам себя... Браво!!!
8 янв 12, 18:25    [11870602]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54813

NOLOCK MS SQL
Дмитрий сегодня превзошел сам себя... Браво!!!

Ах да, я забыл "read nothing". Простая задачка: в таблице есть запись со значением поля
a=1. Одна транзакция делает update t set a=2 where a=1 и не коммитится. Какое значение
получит любая другая транзакция, пытающаяся читать это поле? Версионность отключена,
напоминаю.

Posted via ActualForum NNTP Server 1.5

8 янв 12, 18:59    [11870713]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
У тебя в dirty read
Guest
Dimitry Sibiryakov
NOLOCK MS SQL
Дмитрий сегодня превзошел сам себя... Браво!!!

Ах да, я забыл "read nothing". Простая задачка: в таблице есть запись со значением поля
a=1. Одна транзакция делает update t set a=2 where a=1 и не коммитится. Какое значение
получит любая другая транзакция, пытающаяся читать это поле? Версионность отключена,
напоминаю.

У тебя в dirty read получит a=2, а у всех остальных будет ждать завершения первой транзакции и снятия X-блокировки.
8 янв 12, 19:09    [11870759]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54813

Ну как я и сказал: read nothing.

Posted via ActualForum NNTP Server 1.5

8 янв 12, 19:20    [11870822]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
А причем тут блокировочник/версионник к оптимистическому/пессимистическому накладыванию блокировки?
Хотя конечно они сильно связаны, но это все-таки разные понятия, как длина и вес.
Никто вам не мешает на версионнике сделать select for update и получить пессимистическую блокировку. Надо использовать просто более подходящий инструмент для решения конкретной задачи исходя из природы ее блокировок.
8 янв 12, 21:26    [11871312]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
пессимистической и оптимистическ,


Возьмем, Оракл. Это прост позволит отвлечься от проблем грязного чтения и заняться только конфликтами записи.

Вообще-то, эти блокировки типа планируемые разработчиком приложения, и от СУБД требунтся предоставление возможности управлять блокировками.

Писсимистическая блокировка - конфиликты ожидаются частыми. Тогда предпочтительнее сессиям планирующим менять одну и ту же запись, начинать делать это убедившись, что никто этим еще не начал заниматься. В Оракле есть для этого в SELECT конструкция For Update.
Клиентская прога предназнченная для редактиравования, выполнит не просто SELECT а SELECT For Update. В этом случе любой другой запрос с For Update, а это все , в данном приложении, кто тоже собирается редактировать (тем более обычно в кленте одно окно для редактирования одних и тех же структур данных), и потому тоже юзают SELECT For Update, не смогут выполнить такой запрос, пока первая не разблокирует заблокированный ресурс. Чтение - просто SELECT данных до начала изменений доступно (но это другое окно в приложении).
Недостаток: юзера с помощью окон для редактирования в таком приложении не смогут даже прочитать заблокирование. Тока с окнами для чтений. Но ведь еще хуже, если бы они смогли часто, два часа редактирвать, а потом получать: "Запись изменена другим пользователем. Измененичя не возможны" - это то, что делает оптимистическая блокировка.
Она потому и оптимистическая, что предполагает, что такое редко произойдет.
Такая блокировка предполагает чтение просто SELECT и сохранение в своих переменных прочитанного. Далее юзер меняет себе спокойно переменные в проге, а вот перед попыткой выполнить сохранение изменений в БД опять производится чтение, для надежности возможно даже с For Update и сравнивается с тем, что было в начале.
Если сопало, то БД обновляентся иначе отепз от сохранения. Вся работа по редактироаванию пропала.
Недостаток: юзер будет обеспокоен тем, что зря старался. Достоинство, он сможет читать оконм для редактирования.
Не создавать же 10 окон, условно говоря, для одной таблы.
Оптимистическая блокировка, часто уже реализованая в компонентах юзаемых для создания клиентом производителем этих компонент. Например, в Директ Оракл Аксесс Дельфи. Ну та пессимичтичную моно наложить, если надо поверх.


На практике наблюдал отсутсвие обоих блокировок. Ну это видимо сверхоптимистичная уж не знаю что. Недостато, юзер набирал два часа, думает, что все сохранено, а оно на самом деле пропало. Када это всплывет, юзра могоут не просто обеспокоиться, но даже озаботиться. И не тока те, что набирали.
9 янв 12, 14:57    [11874133]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54813

vadiminfo
На практике наблюдал отсутсвие обоих блокировок. Ну это видимо сверхоптимистичная уж не
знаю что. Недостато, юзер набирал два часа, думает, что все сохранено, а оно на самом деле
пропало. Када это всплывет, юзра могоут не просто обеспокоиться, но даже озаботиться.

Не, эти тормоза не обеспокоятся, поскольку как раз их-то изменения - сохранятся.
Обеспокоиться могли бы те, кто набирал только полтора часа, поскольку именно их изменения
были затёрты теми, что набирались два часа...

Posted via ActualForum NNTP Server 1.5

9 янв 12, 15:04    [11874176]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
пессимистической и оптимистическ
Guest
vadiminfo
Недостаток: юзера с помощью окон для редактирования в таком приложении не смогут даже прочитать заблокирование. Тока с окнами для чтений.

Кстати, для Firebird'a есть возможность в одном и том же гриде для просмотра использовать одну транзакцию с простым SELECT, а для редактирования в этом же гриде другую транзакцию с SELECT For Update. В FibPlus на сколько я помню даже не 2, а целых 4 различных SQL можно прописывать: Select, Update, Delete, Insert.
http://ibase.ru/devinfo/pslock.htm
автор
Гораздо более логичным и удобным является комплект FIBPlus, разработанный на той же основе (FIBC by Gregory Deatz), в котором UpdateSQL датасета может выполняться не в той транзакции, что Select и Refresh. То есть, представление набора записей в контролах типа DBGrid выполняется в одной длинной read only транзакции, а изменение данных – в короткой другой, возможно, отличающейся уровнем изоляции.

По моему под Oracle в DOA тоже нечто такое есть?

vadiminfo
Оптимистическая блокировка, часто уже реализованая в компонентах юзаемых для создания клиентом производителем этих компонент. Например, в Директ Оракл Аксесс Дельфи. Ну та пессимичтичную моно наложить, если надо поверх.

На практике наблюдал отсутсвие обоих блокировок. Ну это видимо сверхоптимистичная уж не знаю что. Недостато, юзер набирал два часа, думает, что все сохранено, а оно на самом деле пропало. Када это всплывет, юзра могоут не просто обеспокоиться, но даже озаботиться. И не тока те, что набирали.

Т.е. если специальных действий не предпринимать и не использовать компоненты в которых реализованы блокировки, то сами Oracle и Firebird не будут использовать ни оптимистическую, ни пессимистическую блокировку, а просто, кто последний закоммитил - того и данные в базе?
9 янв 12, 16:09    [11874486]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54813

пессимистической и оптимистическ
По моему под Oracle в DOA тоже нечто такое есть?

Нету. Оракул ограничен одной транзакцией на коннект.

Posted via ActualForum NNTP Server 1.5

9 янв 12, 17:09    [11874691]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54813

пессимистической и оптимистическ
если специальных действий не предпринимать и не использовать компоненты в которых
реализованы блокировки, то сами Oracle и Firebird не будут использовать ни
оптимистическую, ни пессимистическую блокировку, а просто, кто последний закоммитил - того
и данные в базе?

У Оракула - да. У Firebird - один из них получит ошибку, тот самый update conflict.

Posted via ActualForum NNTP Server 1.5

9 янв 12, 17:11    [11874702]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
Dimitry Sibiryakov
Нету. Оракул ограничен одной транзакцией на коннект.

Ну во-первых, это не совсем так (ну а на самом деле даже совсем не так), во-вторых, никто не требует ограничиваться одним коннектом. Вопрос только в том, что в общем нет причин так извращаться.

vadiminfo
На практике наблюдал отсутсвие обоих блокировок. Ну это видимо сверхоптимистичная уж не знаю что.

Не обязательно. Есть третий и вполне правильный вариант - доступность операции по бизнес-логике.
9 янв 12, 17:20    [11874734]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
пессимистической и оптимистическ
Guest
Dimitry Sibiryakov
пессимистической и оптимистическ
По моему под Oracle в DOA тоже нечто такое есть?

Нету. Оракул ограничен одной транзакцией на коннект.

Ну так 2 конекта - 2 транзакции (возможно с разными уровнями изоляции) - одна читает, другая меняет, все как и в Firebird+FibPlus:
http://ibase.ru/devinfo/pslock.htm
автор
Гораздо более логичным и удобным является комплект FIBPlus, разработанный на той же основе (FIBC by Gregory Deatz), в котором UpdateSQL датасета может выполняться не в той транзакции, что Select и Refresh. То есть, представление набора записей в контролах типа DBGrid выполняется в одной длинной read only транзакции, а изменение данных – в короткой другой, возможно, отличающейся уровнем изоляции.


softwarer
Dimitry Sibiryakov
Нету. Оракул ограничен одной транзакцией на коннект.

Ну во-первых, это не совсем так (ну а на самом деле даже совсем не так), во-вторых, никто не требует ограничиваться одним коннектом. Вопрос только в том, что в общем нет причин так извращаться.

Не, ну потерять данные одной из транзакции причем без осознания этого тоже не очень вариант.
А на уровне СУБД в Oracle можно "включить" оптимистическую блокировку по аналогии с Firebird или только через компоненты доступа?
9 янв 12, 17:48    [11874830]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54813

пессимистической и оптимистическ
Ну так 2 конекта - 2 транзакции (возможно с разными уровнями изоляции)

И вот оно: лицензионное ограничение количества пользовательских сессий.

Posted via ActualForum NNTP Server 1.5

9 янв 12, 17:57    [11874851]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
пессимистической и оптимистическ
Не, ну потерять данные одной из транзакции причем без осознания этого тоже не очень вариант.

Это не имеет ни малейшего отношения к количеству коннектов и транзакций.

пессимистической и оптимистическ
А на уровне СУБД в Oracle можно "включить" оптимистическую блокировку по аналогии с Firebird или только через компоненты доступа?

Я не очень понял Ваше противопоставление.... то, что включается через фибплюсы или аналогичные специальные меры на клиенте, не кажется мне включаемым "на уровне СУБД".

На уровне СУБД пожалуй что в любой СУБД такой режим включается через serializable. Впрочем, не уверен, что стал бы рекомендовать такое решение. Оптимистическую блокировку в Oracle правильнее всего, наверное, делать через ORA_ROWSCN - это псевдоколонка таблицы, показывающая когда (каким номером транзакции) в последний раз модифицировалась указанная запись.
9 янв 12, 18:01    [11874863]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить