|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
softwarer"Классический", надеюсь, не всегда синоним слова "тупой". Корректно проверить все старые значения полей обычно немного тяжеловато, ибо во-первых, из-за null-ов, сравнение получается громоздким, во-вторых, блобы обычно немного неудобно сравнивать на равенство, в-третьих, объёмы... Если условие во where генерирует какой-то framework (или дельфийский компонент, или подобное; заодно оно может понимать, какие поля NOT NULL, и учесть это), то за громоздкость и объёмы можно не переживать, просто не смотря лишний раз на генерируемый код. Но решение с version я только в TOPLink'е видел. (Наверное, есть и в GLORP-е, наследнике TOPLink'а, но я не интересовался). ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 13:52 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Victor MetelitsaКлассический вариант, который я видел "везде" - проверить все старые значения полей. How to use the timestamp column of a table for optimistic concurrency control in SQL Server ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 15:56 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Я правильно понимаю, что в крайних случаях: - пессимистический подход ближе к блокировочникам, есть вероятность deadlock, но не возможен update conflict - оптимистический подход ближе к версионникам, мало вероятен(в некоторых вариантах реализации не возможен) deadlock, но появляется вероятность update conflict Вот тут уже выше давали ссылки: http://atamanenko.blogspot.com/2009/04/blog-post_22.html авторИспользование оптимистичных блокировок позволяет избежать взаимных блокировок (dead-lock). Например в блокировочнике MS SQL про update conflict никто и не слышал . http://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 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 16:09 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
optimistic concurrencyVictor MetelitsaКлассический вариант, который я видел "везде" - проверить все старые значения полей. How to use the timestamp column of a table for optimistic concurrency control in SQL Server Ну, я и не вездесущ. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 16:13 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Я правильно понимаюв блокировочнике MS SQL про update conflict никто и не слышал Там у них про транзакции вообще слышал далеко не каждый второй. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 16:16 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Я правильно понимаюЯ правильно понимаю, что в крайних случаях: - пессимистический подход ближе к блокировочникам, есть вероятность deadlock, но не возможен update conflict - оптимистический подход ближе к версионникам, мало вероятен(в некоторых вариантах реализации не возможен) deadlock, но появляется вероятность update conflict "Оптимистичность" - в голове у разработчика, который создаёт приложение. Оптимистичный подход (наверняка нам никто не помешает) должен быть примерно одинаков и там, и там, поскольку (по возможности) избегаются блокировки. Пессимистический (нам кто-то может помешать, и мы должны это предотвратить) же требует блокировок, а потому здесь возникают нюансы. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 16:33 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Я правильно понимаюНапример в блокировочнике MS SQL про update conflict никто и не слышал . MS SQL уже давно не только блокировочник. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 16:34 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
неправильно понимаешьЯ правильно понимаюНапример в блокировочнике 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 или репликацией? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 17:12 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Victor MetelitsaЯ правильно понимаюЯ правильно понимаю, что в крайних случаях: - пессимистический подход ближе к блокировочникам, есть вероятность deadlock, но не возможен update conflict - оптимистический подход ближе к версионникам, мало вероятен(в некоторых вариантах реализации не возможен) deadlock, но появляется вероятность update conflict "Оптимистичность" - в голове у разработчика, который создаёт приложение. Оптимистичный подход (наверняка нам никто не помешает) должен быть примерно одинаков и там, и там, поскольку (по возможности) избегаются блокировки. Пессимистический (нам кто-то может помешать, и мы должны это предотвратить) же требует блокировок, а потому здесь возникают нюансы. Безусловно нам никто ничего не мешает. Можно и в версионнике много чего блокировать и в блокировочнике хранить версии записей и много чего ещё неестественного накрутить. Но интересует их профильное использование. У кого-нибудь есть ответ, уточнения или конструктивная критика такого обобщения? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 17:18 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Я правильно понимаюты утверждаешь что в MS SQL без использования MVC... ....есть только один уровень изоляции транзакций - Dirty Read, вследствие чего работающие с ним люди вообще о транзакциях не думают. И таки да, на этом уровне эту ошибку получить нельзя. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 18:13 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovЯ правильно понимаюты утверждаешь что в MS SQL без использования MVC... ....есть только один уровень изоляции транзакций - Dirty Read, вследствие чего работающие с ним люди вообще о транзакциях не думают. И таки да, на этом уровне эту ошибку получить нельзя. По моему ты единственный кто пользуется Dirty Read... ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 18:24 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovЯ правильно понимаюты утверждаешь что в MS SQL без использования MVC... .... есть только один уровень изоляции транзакций - Dirty Read , вследствие чего работающие с ним люди вообще о транзакциях не думают. Дмитрий сегодня превзошел сам себя... Браво!!! ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 18:25 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
NOLOCK MS SQLДмитрий сегодня превзошел сам себя... Браво!!! Ах да, я забыл "read nothing". Простая задачка: в таблице есть запись со значением поля a=1. Одна транзакция делает update t set a=2 where a=1 и не коммитится. Какое значение получит любая другая транзакция, пытающаяся читать это поле? Версионность отключена, напоминаю. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 18:59 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovNOLOCK MS SQLДмитрий сегодня превзошел сам себя... Браво!!! Ах да, я забыл "read nothing". Простая задачка: в таблице есть запись со значением поля a=1. Одна транзакция делает update t set a=2 where a=1 и не коммитится. Какое значение получит любая другая транзакция, пытающаяся читать это поле? Версионность отключена, напоминаю. У тебя в dirty read получит a=2, а у всех остальных будет ждать завершения первой транзакции и снятия X-блокировки. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 19:09 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Ну как я и сказал: read nothing. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 19:20 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
А причем тут блокировочник/версионник к оптимистическому/пессимистическому накладыванию блокировки? Хотя конечно они сильно связаны, но это все-таки разные понятия, как длина и вес. Никто вам не мешает на версионнике сделать select for update и получить пессимистическую блокировку. Надо использовать просто более подходящий инструмент для решения конкретной задачи исходя из природы ее блокировок. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 21:26 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическ, Возьмем, Оракл. Это прост позволит отвлечься от проблем грязного чтения и заняться только конфликтами записи. Вообще-то, эти блокировки типа планируемые разработчиком приложения, и от СУБД требунтся предоставление возможности управлять блокировками. Писсимистическая блокировка - конфиликты ожидаются частыми. Тогда предпочтительнее сессиям планирующим менять одну и ту же запись, начинать делать это убедившись, что никто этим еще не начал заниматься. В Оракле есть для этого в SELECT конструкция For Update. Клиентская прога предназнченная для редактиравования, выполнит не просто SELECT а SELECT For Update. В этом случе любой другой запрос с For Update, а это все , в данном приложении, кто тоже собирается редактировать (тем более обычно в кленте одно окно для редактирования одних и тех же структур данных), и потому тоже юзают SELECT For Update, не смогут выполнить такой запрос, пока первая не разблокирует заблокированный ресурс. Чтение - просто SELECT данных до начала изменений доступно (но это другое окно в приложении). Недостаток: юзера с помощью окон для редактирования в таком приложении не смогут даже прочитать заблокирование. Тока с окнами для чтений. Но ведь еще хуже, если бы они смогли часто, два часа редактирвать, а потом получать: "Запись изменена другим пользователем. Измененичя не возможны" - это то, что делает оптимистическая блокировка. Она потому и оптимистическая, что предполагает, что такое редко произойдет. Такая блокировка предполагает чтение просто SELECT и сохранение в своих переменных прочитанного. Далее юзер меняет себе спокойно переменные в проге, а вот перед попыткой выполнить сохранение изменений в БД опять производится чтение, для надежности возможно даже с For Update и сравнивается с тем, что было в начале. Если сопало, то БД обновляентся иначе отепз от сохранения. Вся работа по редактироаванию пропала. Недостаток: юзер будет обеспокоен тем, что зря старался. Достоинство, он сможет читать оконм для редактирования. Не создавать же 10 окон, условно говоря, для одной таблы. Оптимистическая блокировка, часто уже реализованая в компонентах юзаемых для создания клиентом производителем этих компонент. Например, в Директ Оракл Аксесс Дельфи. Ну та пессимичтичную моно наложить, если надо поверх. На практике наблюдал отсутсвие обоих блокировок. Ну это видимо сверхоптимистичная уж не знаю что. Недостато, юзер набирал два часа, думает, что все сохранено, а оно на самом деле пропало. Када это всплывет, юзра могоут не просто обеспокоиться, но даже озаботиться. И не тока те, что набирали. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 14:57 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
vadiminfoНа практике наблюдал отсутсвие обоих блокировок. Ну это видимо сверхоптимистичная уж не знаю что. Недостато, юзер набирал два часа, думает, что все сохранено, а оно на самом деле пропало. Када это всплывет, юзра могоут не просто обеспокоиться, но даже озаботиться. Не, эти тормоза не обеспокоятся, поскольку как раз их-то изменения - сохранятся. Обеспокоиться могли бы те, кто набирал только полтора часа, поскольку именно их изменения были затёрты теми, что набирались два часа... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 15:04 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
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 не будут использовать ни оптимистическую, ни пессимистическую блокировку, а просто, кто последний закоммитил - того и данные в базе? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 16:09 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическПо моему под Oracle в DOA тоже нечто такое есть? Нету. Оракул ограничен одной транзакцией на коннект. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 17:09 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическесли специальных действий не предпринимать и не использовать компоненты в которых реализованы блокировки, то сами Oracle и Firebird не будут использовать ни оптимистическую, ни пессимистическую блокировку, а просто, кто последний закоммитил - того и данные в базе? У Оракула - да. У Firebird - один из них получит ошибку, тот самый update conflict. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 17:11 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovНету. Оракул ограничен одной транзакцией на коннект. Ну во-первых, это не совсем так (ну а на самом деле даже совсем не так), во-вторых, никто не требует ограничиваться одним коннектом. Вопрос только в том, что в общем нет причин так извращаться. vadiminfoНа практике наблюдал отсутсвие обоих блокировок. Ну это видимо сверхоптимистичная уж не знаю что. Не обязательно. Есть третий и вполне правильный вариант - доступность операции по бизнес-логике. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 17:20 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
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 транзакции, а изменение данных – в короткой другой, возможно, отличающейся уровнем изоляции. softwarerDimitry SibiryakovНету. Оракул ограничен одной транзакцией на коннект. Ну во-первых, это не совсем так (ну а на самом деле даже совсем не так), во-вторых, никто не требует ограничиваться одним коннектом. Вопрос только в том, что в общем нет причин так извращаться. Не, ну потерять данные одной из транзакции причем без осознания этого тоже не очень вариант. А на уровне СУБД в Oracle можно "включить" оптимистическую блокировку по аналогии с Firebird или только через компоненты доступа? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 17:48 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическНу так 2 конекта - 2 транзакции (возможно с разными уровнями изоляции) И вот оно: лицензионное ограничение количества пользовательских сессий. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 17:57 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическНе, ну потерять данные одной из транзакции причем без осознания этого тоже не очень вариант. Это не имеет ни малейшего отношения к количеству коннектов и транзакций. пессимистической и оптимистическА на уровне СУБД в Oracle можно "включить" оптимистическую блокировку по аналогии с Firebird или только через компоненты доступа? Я не очень понял Ваше противопоставление.... то, что включается через фибплюсы или аналогичные специальные меры на клиенте, не кажется мне включаемым "на уровне СУБД". На уровне СУБД пожалуй что в любой СУБД такой режим включается через serializable. Впрочем, не уверен, что стал бы рекомендовать такое решение. Оптимистическую блокировку в Oracle правильнее всего, наверное, делать через ORA_ROWSCN - это псевдоколонка таблицы, показывающая когда (каким номером транзакции) в последний раз модифицировалась указанная запись. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 18:01 |
|
|
start [/forum/topic.php?fid=35&msg=37605673&tid=1552601]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 147ms |
0 / 0 |