|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
В чем отличие пессимистической и оптимистической стратегии в блокировочнике и версионнике и в каком случае возможен и/или наиболее вероятен update conflict, а в каком deadlock? Насколько я понимаю: 1. Блокировочник: 1.1. Пессиместическая: накладывается U-блокировка на все прочитанные данные и X-на все измененные. Наиболее вероятен Deadlock. Не возможен Update Conflict. 1.2. Оптимистическая: накладывается S-блокировка только на момент чтения, как только трока прочитана - блокировка снимается. На все измененные накладывается X-блокировка. Менее вероятен чем в (1.1), но все же возможен Deadlock. Возможен Update Conflict, но не понятно по каким критериям его определит СУБД. 2. Версионник: 2.1. Пессиместическая: при чтении никакие блокировки не накладываются, а при изменениях накладываются X-блокировки. Вероятность Deadlock меньше чем у версионника (1.1) и (1.2). Не возможен Update Conflict. 2.2. Оптимистическая: ни при чтении, ни при записи никакие блокировки не накладываются. Deadlock невозможен. Возможен Update Conflict, но опять же не понятно по каким критериям его определит СУБД. И какой стратегии придерживаются различные СУБД: Oracle, PostgreSQL, MS SQL, Firebird? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2012, 13:34 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
что-то в последнее время многовато появляются тем от анонимов, которые потом просто скатываются в срач. Вот и сейчас, кажется что вот снова начнется. И откуда столько троллей. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2012, 13:47 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическ2. Версионник: Пытаться описать работу версионника в терминах блокировочника - заведомо провальная стратегия. Они работают совсем не так. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2012, 13:51 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
А полльзовался ли ТС поиском,перед тем как задать вопрос? Там столько доступной инфы, например вот кратко: http://atamanenko.blogspot.com/2009/04/blog-post_22.html ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2012, 13:53 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
или википедия: http://ru.wikipedia.org/wiki/%C1%EB%EE%EA%E8%F0%EE%E2%EA%E0_(%D1%D3%C1%C4) та мля,столько инфы. Автор, идите лучше на ... в гугл... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2012, 13:55 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Ggg_oldчто-то в последнее время многовато появляются тем от анонимов, которые потом просто скатываются в срач. Вот и сейчас, кажется что вот снова начнется. И откуда столько троллей. Не нервничай. По делу есть что сказать? Модератор удалите оффтоп Ggg_old. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2012, 13:56 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovпессимистической и оптимистическ2. Версионник: Пытаться описать работу версионника в терминах блокировочника - заведомо провальная стратегия. Они работают совсем не так. А как он работает? На уровне синхронизации многопоточности все реализуется и соответственно описывается через блокировки, в том числе версионники. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2012, 13:59 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическ<...> 2. Версионник: 2.1. Пессиместическая: при чтении никакие блокировки не накладываются, а при изменениях накладываются X-блокировки. Вероятность Deadlock меньше чем у версионника (1.1) и (1.2). Не возможен Update Conflict. 2.2. Оптимистическая: ни при чтении, ни при записи никакие блокировки не накладываются. Deadlock невозможен. Возможен Update Conflict, но опять же не понятно по каким критериям его определит СУБД. <...> Firebird? Сеанс в Firebird всегда сразу блокирует запись при выполнении update/delete. Другие сеансы точно не смогут изменить эту запись, а при работе в транзакции с no record_version - не смогут даже прочитать эту запись и все остальные после неё в порядке их обработки. Разумеется, из-за этого они не смогут и обновить такие записи (ведь их сначала надо найти - т.е. прочитать ). Session #1. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Session #2. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2012, 14:07 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
А как он работает?На уровне синхронизации многопоточности все реализуется и соответственно описывается через блокировки, в том числе версионники. Да, для синхронизации многопоточности используются блокировки, конечно. Но блокировки разделяемых ресурсов и блокировки записей это две большие разницы. RTFM: http://www.ibphoenix.com/resources/documents/search/doc_27 http://ibase.ru/devinfo/mga.htm Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2012, 14:08 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Смешались в кучу кони, люди... ((с) М.Ю. Лермонтов. Бородино) пессимистической и оптимистическИ какой стратегии придерживаются различные СУБД: Oracle, PostgreSQL, MS SQL, Firebird? А СУБД то здесь причем, если выбор стратегии "оптимистическая" или "пессимистичекая" лежит полностью на плечах разработчика?! Update Conflict в блокировочнике при выбранной оптимистической стратегии, опять же, без дополнительных телодвижений со стороны разработчика не то, чтобы не разрешим самой СУБД, он ей не детектируем. Какую задачу пытаемся решить? Обсудить как каждая из СУБД, поддерживающая версионность, детектирует и разрешает Update Conflict? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2012, 15:13 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Блокировочник vs ВерсионникUpdate Conflict в блокировочнике при выбранной оптимистической стратегии, опять же, без дополнительных телодвижений со стороны разработчика не то, чтобы не разрешим самой СУБД, он ей не детектируем. А Update Conflict в блокировочнике вообще возможен? S-блокировка накладывается на все что читаем, X-на все что меняем, U-помогает избежать deadlock при изменении после чтения. Везде где наложена любая из этих блокировок изменение данных другими транзакциями не возможно - соответственно не возможен Update Conflict. Допустим: http://www.sql.ru/forum/afsearch.aspx?s=Update+Conflict&submit=%CD%E0%E9%F2%E8&bid=1 По этим словам в MS SQL только либо конфликт с FK, либо в версионной транзакции. Блокировочник vs ВерсионникКакую задачу пытаемся решить? Обсудить как каждая из СУБД, поддерживающая версионность, детектирует и разрешает Update Conflict? Да, именно что. Особенно интересует оптимистическая стратегия в версионниках и разрешение Update Conflict в них. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2012, 01:05 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическОсобенно интересует оптимистическая стратегия в версионниках и разрешение Update Conflict в них. А Вам не приходило в голову, что каждый сервер это делает по-разному? И даже один и тот же - в разных ситуациях?.. Firebird, например, детектирует update conflict по наличию версии записи с номером больше чем ожидаемый. Но никогда сама не пытается этот конфликт разрешить, честно сообщая о нём пользователю. Oracle - наоборот, разрешает конфликт откатывая один из запросов и пытаясь начать всё заново. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2012, 01:28 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovпессимистической и оптимистическОсобенно интересует оптимистическая стратегия в версионниках и разрешение Update Conflict в них. А Вам не приходило в голову, что каждый сервер это делает по-разному? И даже один и тот же - в разных ситуациях?.. Firebird, например, детектирует update conflict по наличию версии записи с номером больше чем ожидаемый. Но никогда сама не пытается этот конфликт разрешить, честно сообщая о нём пользователю. Oracle - наоборот, разрешает конфликт откатывая один из запросов и пытаясь начать всё заново. Так именно по этому и спрашиваю, что не знаю всех вариантов. Т.е. Firebird при commit блокирует список всех всех прочтенных в этой транзакции записей, кстати он наверное иногда очень большой получается. Пробегает по этому списку и для каждой записи в ней смотрит последнюю версию. Ну а блокирует видимо для того, чтобы пока он это все делает не появилось новых записей, правильно? Т.е. Firebird блокирует строки только изменяемые и только на время изменения записей и все строки во время commit? А способы возникновения update conflict в Oracle и Firebird схожи, т.е. всегда когда другая транзакция меняет любую строчку которая читалась/менялась в нашей транзакции? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2012, 01:44 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическТ.е. Firebird при commit блокирует список всех всех прочтенных в этой транзакции записей Нет, конечно. Такую глупость могут только блокировочники. Конфликт обнаруживается непосредственно при изменении записи. Есть два номера транзакций: тот, который был прочтён перед изменением записи и тот, который у записи на диске теперь. Не совпадают - в морг. Не сразу, там много чего ещё наворочено типа параметров транзакций и обнаружения мёртвых транзакций, но при нормальном течении событий - в морг. пессимистической и оптимистическТ.е. Firebird блокирует строки только изменяемые и только на время изменения записей и все строки во время commit? Нет, Firebird вообще не блокирует записи (только разделяемые ресурсы, такие как буфер страницы в кэше) и тем более - при commit. Я же, блин, выше уже дал две ссылки. Чукча не читатель?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2012, 02:10 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovпессимистической и оптимистическТ.е. Firebird при commit блокирует список всех всех прочтенных в этой транзакции записей Нет, конечно. Такую глупость могут только блокировочники. Конфликт обнаруживается непосредственно при изменении записи. Есть два номера транзакций: тот, который был прочтён перед изменением записи и тот, который у записи на диске теперь. Не совпадают - в морг. Не сразу, там много чего ещё наворочено типа параметров транзакций и обнаружения мёртвых транзакций, но при нормальном течении событий - в морг. Понял. Откатывается Update Statment с ошибкой Update Conflict если во время него кто-то изменил то, что он тоже менял. А дальше клиент повторяет операцию и если предыдущая помешавшая транзакция ещё не закомитилась, т.е. Update Statment нарвался на незакомиченные версии, то в зависимости от wait/no wait ждет пока она закомитится (аки блокировку, но не блокировку). А если no wait, то снова откатывает Update Statment, но уже не с Update Conflict, а с Lock Conflict(deadlock). А причины возникновения и способы детектирования Update Conflict в Oracle схожи, разница лишь в том, что Oracle автоматом заново проводит Update Statment до тех пор пока не станет успешной? Dimitry Sibiryakovпессимистической и оптимистическТ.е. Firebird блокирует строки только изменяемые и только на время изменения записей и все строки во время commit? Нет, Firebird вообще не блокирует записи (только разделяемые ресурсы, такие как буфер страницы в кэше) и тем более - при commit. Я же, блин, выше уже дал две ссылки. Чукча не читатель?.. Записи не блокируются - блокируется страница на которой лежит запись во время её изменения. Но это уже техническая реализация. Кстати, т.к. Firebird опирается он только на номера версий, и в нем нету блокировок, то он не может пройти по их графу и найти deadlock, по этому в зависимости от wait/no wait он просто предполагает, что это обычное ожидание предыдущей транзакции или Lock Conflict(deadlock). На сколько я понимаю в Oracle тоже нету блокировок и их графа и там разруливается deadlock подобным образом? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2012, 02:31 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическКстати, т.к. Firebird опирается он только на номера версий, и в нем нету блокировок, то он не может пройти по их графу и найти deadlock, Так и не образуется никакого дедлока при самом апдейте. Только при ожидании завершения конкурирующей транзакции, а тут уже граф локов есть. Или таймаут ожидания (в зависимости опять же от параметров). Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2012, 02:48 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovпессимистической и оптимистическКстати, т.к. Firebird опирается он только на номера версий, и в нем нету блокировок, то он не может пройти по их графу и найти deadlock, Так и не образуется никакого дедлока при самом апдейте. Только при ожидании завершения конкурирующей транзакции, а тут уже граф локов есть. Или таймаут ожидания (в зависимости опять же от параметров). Здесь я уже общий случай рассматриваю. Может быть обычный долгий "лок", а может и "дедлок", если та транзакция которую ждут решит изменить запись которую изменил предыдущий стейтмент нашей ждущей транзакции. А вот насчет графа локов не понял. Как может существовать граф блокировок без существования самих блокировок? :) Или имеется ввиду некий граф ожиданий друг друга транзакциями? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2012, 03:04 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическА вот насчет графа локов не понял. Как может существовать граф блокировок без существования самих блокировок? :) Или имеется ввиду некий граф ожиданий друг друга транзакциями? ожидание коммита/роллбека конкурирующей транзакции реализовано через менеджер блокировок, просто уровень блокировок другой (транзакции, а не записи). ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2012, 06:06 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
В документацию по TOPLink/S (универсальный O/R framework для Smalltalk'ов) про их реализацию "оптимизма" рассказывалось так: * в таблице заводится дополнительное поле version (числовое); * обновление (TOPLink'ом) производится так: Код: plsql 1. 2. 3.
(можно также использовать не числовую, а Timestamp'овую version) И если этот UPDATE обновил 1 запись, то всё хорошо. А если 0, то это означает, что кто-то обновил эту запись до, и TOPLink выбрасывает исключение, и разбирайтесь с этим, как знаете (к примеру, уведомите юзера, что кто-то успел раньше). Вот и всё. Конечно, чтобы оно работало на блокировочнике действительно "оптимистично", надо помнить, что даже чтение (обычно) накладывает блокировку. Какая блокировка и на что, каков её срок жизни - зависит от уровня изоляции (а курсор with hold и его блокировки даже переживут commit, хотя не rollback). На блокировочнике надо будет выбрать изоляцию пониже и коммититься почаще. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2012, 12:42 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
поправка Код: plsql 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2012, 13:40 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Victor Metelitsaпоправка Код: plsql 1. 2. 3.
И этот Update Statment крутиться в цикле до первого успешного изменения? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2012, 15:27 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Victor MetelitsaИ если этот UPDATE обновил 1 запись, то всё хорошо. А если 0, то это означает, что кто-то обновил эту запись до, и TOPLink выбрасывает исключение, и разбирайтесь с этим, как знаете (к примеру, уведомите юзера, что кто-то успел раньше). А если UPDATE STATMENT обновляет не 1, а 10 записей, или из 10 возможных обновил только 9 это считается успешным? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2012, 17:41 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическVictor Metelitsaпоправка Код: plsql 1. 2. 3.
И этот Update Statment крутиться в цикле до первого успешного изменения? Я уже сказал - выбрасывается исключение. Как оно будет обрабатываться - уже не забота TOPLink'а. В принципе, цикл здесь подразумевается, но со взаимодействем с пользователем. Пользователь прочитал данные (в какой-то форме), изменил, нажал кнопку "сохранить". Выскочило исключение: "Пока, мол, вы чем-то занимались, данные уже изменились. Теперь они не такие-то, а такие-то. Хотите ли изменить их?". Пользователь, предположим, правит их, нажимает на кнопку сохранить. А ему в ответ - "ой, а эти данные опять кто-то успел изменить". И так далее. Цикл, пока сохранение не пройдёт или пользователю не надоест. Ни о каких 10 записях в этом примере не может быть и речи. Ключ - это первичный или уникальный ключ, обновляется или одна запись, или ни одной. Если расширять пример до N записей (и надо ещё придумать, как), то только N успешно обновлённых записей может быть успехом. Более обще: мы оптимистически предполагаем, что никто на наши данные не покусится, и потому не лочим их. Но если мы каким-то образом обнаружили, что кто-то что-то изменил, то вся транзакция идёт коту под хвост, и разумно выбросить исключение (чтобы спросить пользователя, что с этим делать, или хотя бы как-то разумно обработать, а не просто тупо повторить и затереть чужие исправления). Классический вариант, который я видел "везде" - проверить все старые значения полей. Код: plsql 1. 2. 3.
но вариант выше с version проще и универсальнее (LOB'ы обычно сравнить не так легко). ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2012, 21:16 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Victor MetelitsaКлассический вариант, который я видел "везде" - проверить все старые значения полей. "Классический", надеюсь, не всегда синоним слова "тупой". Корректно проверить все старые значения полей обычно немного тяжеловато, ибо во-первых, из-за null-ов, сравнение получается громоздким, во-вторых, блобы обычно немного неудобно сравнивать на равенство, в-третьих, объёмы... ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 10:55 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
softwarerиз-за null-ов, сравнение получается громоздкимв Firebird есть замечательная конструкция для этого: a is [not] distinct from b. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2012, 12:17 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#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 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovпессимистической и оптимистическНу так 2 конекта - 2 транзакции (возможно с разными уровнями изоляции) И вот оно: лицензионное ограничение количества пользовательских сессий. А поподробнее? А то, похоже, я счастливо отстал от лицензионной политики. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 18:02 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
softwarerА поподробнее? А то, похоже, я счастливо отстал от лицензионной политики. Я тоже, но в семёрке было ограничение на количество сессий, которое, впрочем, увеличивалось в конфиге. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 18:10 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovЯ тоже, но в семёрке было ограничение на количество сессий, которое, впрочем, увеличивалось в конфиге. Ну Вы и вспомнили. Во времена семёрки Firebird и оператора SELECT-то выполнять не умел ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 18:14 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
vadiminfoПиссимистическая блокировка - конфиликты ожидаются частыми. Тогда предпочтительнее сессиям планирующим менять одну и ту же запись, начинать делать это убедившись, что никто этим еще не начал заниматься. В Оракле есть для этого в SELECT конструкция For Update. Клиентская прога предназнченная для редактиравования, выполнит не просто SELECT а SELECT For Update. В этом случе любой другой запрос с For Update, а это все , в данном приложении, кто тоже собирается редактировать (тем более обычно в кленте одно окно для редактирования одних и тех же структур данных), и потому тоже юзают SELECT For Update, не смогут выполнить такой запрос, пока первая не разблокирует заблокированный ресурс. Чтение - просто SELECT данных до начала изменений доступно (но это другое окно в приложении). Недостаток: юзера с помощью окон для редактирования в таком приложении не смогут даже прочитать заблокирование. Тока с окнами для чтений. Но ведь еще хуже, если бы они смогли часто, два часа редактирвать, а потом получать: "Запись изменена другим пользователем. Измененичя не возможны" - это то, что делает оптимистическая блокировка. Она потому и оптимистическая, что предполагает, что такое редко произойдет. Такая блокировка предполагает чтение просто SELECT и сохранение в своих переменных прочитанного. Далее юзер меняет себе спокойно переменные в проге, а вот перед попыткой выполнить сохранение изменений в БД опять производится чтение, для надежности возможно даже с For Update и сравнивается с тем, что было в начале. Если сопало, то БД обновляентся иначе отепз от сохранения. Вся работа по редактироаванию пропала. Недостаток: юзер будет обеспокоен тем, что зря старался. Достоинство, он сможет читать оконм для редактирования. Не создавать же 10 окон, условно говоря, для одной таблы. Оптимистическая блокировка, часто уже реализованая в компонентах юзаемых для создания клиентом производителем этих компонент. Например, в Директ Оракл Аксесс Дельфи. Ну та пессимичтичную моно наложить, если надо поверх. Жуткая кривота и то, и другое. В первом случае существует select for update nowait, и приличное приложение немедленно получит ошибку, если ему заблокировать не удалось. В таком случае оно может перечитать данные простым select'ом. Но это просто неудобства. Во втором случае это натуральный ужас. Почему работа по редактированию пропала? Когда знаем и текущие значения в базе, и значения, введённые юзером, почему их ему не показать и то, и то одновременно, и не помочь? На практике наблюдал отсутсвие обоих блокировок. Ну это видимо сверхоптимистичная уж не знаю что. Недостато, юзер набирал два часа, думает, что все сохранено, а оно на самом деле пропало. Када это всплывет, юзра могоут не просто обеспокоиться, но даже озаботиться. И не тока те, что набирали. Юзера могут быть разведены организационно. Скажем, двум юзерам дали по пачке документов, они занимаются вводом. Третий юзер занимается проверкой. Четвёртый делает отчёты за прошлый введённый месяц. Они друг другу не мешают, и блокировки не причём. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 18:15 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
softwarerВо времена семёрки Firebird и оператора SELECT-то выполнять не умел Зато это умел Interbase. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 18:16 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovпессимистической и оптимистическНу так 2 конекта - 2 транзакции (возможно с разными уровнями изоляции) И вот оно: лицензионное ограничение количества пользовательских сессий. А это где? Оракля и DB2 лицензируют поядерно/попроцессорно/посокетно или же как для named users, у каждого из которых хоть по 10 коннектов... а хоть и ни одного коннекта (т.е., работает через connection pooling) - неважно, он всё равно за 1 сосчитается. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 18:20 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
softwarerпессимистической и оптимистическНе, ну потерять данные одной из транзакции причем без осознания этого тоже не очень вариант. Это не имеет ни малейшего отношения к количеству коннектов и транзакций. Видимо я не совсем понял, что вы имелли ввиду под "нет причин так извращаться" - про два коннекта? softwarerDimitry SibiryakovНету. Оракул ограничен одной транзакцией на коннект. Ну во-первых, это не совсем так (ну а на самом деле даже совсем не так), во-вторых, никто не требует ограничиваться одним коннектом. Вопрос только в том, что в общем нет причин так извращаться. 1. нет причин одновременно просматривать и редактировать? т.е. советуете использовать пессиместическую блокировку с одним коннектом. 2. нет причин использовать пессиместическую блокировку? т.е. советуете использовать оптимистическую блокировку и вероятность перенаобра заново данных. 3. нет причин использовать ни пессиместическую, ни оптимистическую блокировку? и есть вероятность потерять данные. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 18:46 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическА на уровне СУБД в Oracle можно "включить" оптимистическую блокировку по аналогии с Firebird или только через компоненты доступа? Я не очень понял Ваше противопоставление.... то, что включается через фибплюсы или аналогичные специальные меры на клиенте, не кажется мне включаемым "на уровне СУБД". На уровне СУБД пожалуй что в любой СУБД такой режим включается через serializable. Впрочем, не уверен, что стал бы рекомендовать такое решение. Оптимистическую блокировку в Oracle правильнее всего, наверное, делать через ORA_ROWSCN - это псевдоколонка таблицы, показывающая когда (каким номером транзакции) в последний раз модифицировалась указанная запись.[/quot] Не, имеется ввиду, как включить в Oracle то, что работает в Firebird по умолчанию? А именно из цитаты выше: Dimitry Sibiryakovпессимистической и оптимистическесли специальных действий не предпринимать и не использовать компоненты в которых реализованы блокировки, то сами Oracle и Firebird не будут использовать ни оптимистическую, ни пессимистическую блокировку, а просто, кто последний закоммитил - того и данные в базе? У Оракула - да. У Firebird - один из них получит ошибку, тот самый update conflict. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 18:46 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическВидимо я не совсем понял, что вы имелли ввиду под "нет причин так извращаться" - про два коннекта? Про две транзакции. пессимистической и оптимистическ1. нет причин одновременно просматривать и редактировать? т.е. советуете использовать пессиместическую блокировку с одним коннектом. 2. нет причин использовать пессиместическую блокировку? т.е. советуете использовать оптимистическую блокировку и вероятность перенаобра заново данных. 3. нет причин использовать ни пессиместическую, ни оптимистическую блокировку? и есть вероятность потерять данные. Если я правильно понимаю, Вы сваливаете в одну кучу совсем разные вещи. Подумайте о том, что блокировки предназначены для регулирования доступа к данным со стороны разных пользователей, и уже поэтому не имеют прямой связи с вопросом "сколько соединений и транзакций должно использовать приложение, запущенное для конкретного пользователя". Речь же идёт ровно об одном: фибплюсовская схема предназначена для борьбы с архитектурой update conflict. В оракле такой борьбы не требуется, соответственно не требуется её повторять. Технически то же самое делается в оракле в рамках одного соединения, но поступают так редко, ибо незачем. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 19:01 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
softwarerРечь же идёт ровно об одном: фибплюсовская схема предназначена для борьбы с архитектурой update conflict. В оракле такой борьбы не требуется , соответственно не требуется её повторять. Технически то же самое делается в оракле в рамках одного соединения, но поступают так редко, ибо незачем. А в Оракле её нету потому, что данные просто перезаписываются последней закоммитившейся транзакцией или потому, что обновление повотряется автоматически до тех пор пока не пройдет успешно? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 19:14 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическА в Оракле её нету потому, что данные просто перезаписываются последней закоммитившейся транзакцией или потому, что обновление повотряется автоматически до тех пор пока не пройдет успешно? Скорее первое, чем второе. Как, собственно, и в фибплюсовских приложениях. "Обновление повторяется автоматически" - это похоже на пересказ "слышал звон" так называемых оракловых мини-откатов, которые могут возникать, если несколько пользователей пытаются одновременно обновлять частично пересекающиеся множества строк. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 19:25 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
один дурачек (Дмитрий) ерунду спорол, а вы уши развесили что в оракле, что в фаирберд пишушие транзакции идентично расставляют блокировки, Таблойд еще на первой странице все разжувал кодом: http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=908100&msg=11864628 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 19:28 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
пессимистической и оптимистическНе, имеется ввиду, как включить в Oracle то, что работает в Firebird по умолчанию? В Firebird по умолчанию работает TIL snapshot, которого в Оракуле просто нет. Yo.!Таблойд еще на первой странице все разжувал кодом: Таблоид кодом разжевал крайний случай, который ни один вменяемый разработчик использовать не станет. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 19:51 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovТаблоид кодом разжевал крайний случай, который ни один вменяемый разработчик использовать не станет. крайний случай - это ты. закусывай уже, праздники кончились. глядишь и снепшот найдется в оракле. хотя учитывая, что случай крайний - не факт, что у тебя найдется. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 20:09 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Yo.!глядишь и снепшот найдется в оракле Как же, как же, помню этот ваш смешной serializable с версионностью уровня страницы. Да и запрет на чтение изменяемой таблицы тоже найдётся... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 20:35 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovserializable с версионностью уровня страницы вот по тому я и говорю - дурачка не слушать ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 20:44 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Yo.!вот по тому я и говорю - дурачка не слушать Нет, я конечно, помню, что существует танец с бубном, от которого и без того невысокое быстродействие падает ещё ниже плинтуса... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 20:48 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovНет, я конечно, помню, что существует танец с бубном, от которого и без того невысокое быстродействие падает ещё ниже плинтуса... вот потому Yo! и зарабатывает себе и на икорку, что у всяких дурачков то снепшот потерялся, то что-то падает и это правильно ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 21:02 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Yo.!что в оракле, что в фаирберд пишушие транзакции идентично расставляют блокировки,Что-то мне пока не бросилось в глаза... я могу ошибаться, но: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 21:23 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
ТаблоидЧто-то мне пока не бросилось в глаза... я могу ошибаться, но: На очень беглый взгляд это известная багофича старых версий "программист забыл создать индекс на внешний ключ". ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 21:59 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Хотя стоп, он же не внешний. Просто делаете вставку дублирующихся значений. Да, есть такая особенность. Версионная, я бы сказал ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 22:05 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Таблоид, не понял примера. что ФБ позволит вставить третью запись не смотря на констреинт ? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 22:15 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Yo.!не понял примера. что ФБ позволит вставить третью запись не смотря на констреинт ? Ну а почему нет? Оракл, собственно, тоже вроде позволит, если сделать констрейнт отложенным. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 22:29 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Yo.!ФБ позволит вставить третью запись не смотря на констреинт ?Нет. Не позволит. Второй сеанс при указании wait (default) будет также ждать до посинения, при указании no wait получит сразу же шваброй: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 22:48 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
ТаблоидНет. Не позволит. Второй сеанс при указании wait (default) будет также ждать до посинения ну так вроде идентично ораклу ... ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 22:57 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Yo.!ну так вроде идентично ораклу ...Это только при задании параметра wait. Меня интересует (не праздно, причём), как сделать в Oracle немедленную, а еще лучше - с назначаемым таймаутом, реакцию для сеанса номер 2, который пытается выполнить изменение, приводящее к дублю. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2012, 00:03 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
ТаблоидМеня интересует как сделать в Oracle А никак, обломись. Впрочем Александр Рындин что-то говорил про improvement request-ы, которые теоретически в контору Ларри можно посылать... Может, версии к двадцатой, они его и рассмотрят... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2012, 00:50 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
ТаблоидЭто только при задании параметра wait. Меня интересует (не праздно, причём), как сделать в Oracle немедленную, а еще лучше - с назначаемым таймаутом, реакцию для сеанса номер 2, который пытается выполнить изменение, приводящее к дублю. хрен знает, я по части изврата не самый крупный специалист. у меня на ожидание юзерского инпута строгое табу, потому изврата не требуется. вообще в оракле есть конструкция select .. for update wait 5; (или nowait) для таких случаев, но тут наверно не подойдет. тут вероятно можно извратиться через merge типа merge ... then matched update ... where 1=2 then not matced insert ... т.е. если запись есть апдейтим 0 строк, но я бы все таки советовал в консерватории, что-то менять. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2012, 01:11 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovТаблоидМеня интересует как сделать в Oracle А никак, обломись. Впрочем Александр Рындин что-то говорил про improvement request-ы, которые теоретически в контору Ларри можно посылать... Может, версии к двадцатой, они его и рассмотрят... А чего в контору слать, можно непосредственно "Ларри "слать. В смысле ему, а не его ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2012, 01:18 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Yo.!у меня на ожидание юзерского инпута строгое табу, потому изврата не требуется Табу, никаких инсертов от пользователей? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2012, 01:20 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
ТабуYo.!у меня на ожидание юзерского инпута строгое табу, потому изврата не требуется Табу, никаких инсертов от пользователей? если не доходит с первого раза попробуй прочесть еще раз. тут извени, уж разжевывать не буду ... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2012, 01:36 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Yo.!Табупропущено... Табу, никаких инсертов от пользователей? если не доходит с первого раза попробуй прочесть еще раз. тут извени, уж разжевывать не буду ...Какое строгое табу, даже говорить на эту тему не осмеливаешься. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2012, 02:12 |
|
Отличие пессимистической и оптимистической стратегии
|
|||
---|---|---|---|
#18+
Victor Metelitsa Жуткая кривота и то, и другое. В первом случае существует select for update nowait, и приличное приложение немедленно получит ошибку, если ему заблокировать не удалось. В таком случае оно может перечитать данные простым select'ом. Но это просто неудобства. Во втором случае это натуральный ужас. Почему работа по редактированию пропала? Когда знаем и текущие значения в базе, и значения, введённые юзером, почему их ему не показать и то, и то одновременно, и не помочь? Я пытался концепцию пояснить и намеренно уклонялся от деталей. Тока для иллюстрации. nowait - опция конструкции for update. В моем тексте, так как я не сказал, что вторая непременно зависнет пока первая не разблокирует (for update без nowait). Это уже кто какой сценарий придумает в зависмости от своей специфики требований. Второй селект - тем более детали конкретных сценариев, но я вроде писал что читать, т.е. простой select канает в Оракле, потому не отрицал этого. Так что не понял Вашу мыстль. Я не пытался написать сценарий на все случаи, и не считаю что он должент быть обязательно один. Т.е. главное, что окно для редактирования (а не любое) не сможет прочитать (хоть с nowait хоть без поскоку есть for update) раз разработчик решил юзать писсиместическую блокировку. Нет он, конечно, может в слкучае если не проканает for update, выполнить просто select в том же окне, но написать что редпактирование не возмрожно, но это уже излишние дополнения к конценпции. Что до второго, то не знаю, почему, но пропадает на практике из того что я видел. Ну если Вы юзаете стандартные средства. Про Дельфи писал. Ну у Аксцесса есть, наскока помню. Пропадает. Ну потому и термин оптимистическая, что это не часто. Ну если придумаете как сохранить,то наздоровье. Но думау, это дополнительные усилия, раз на них не пошли стандартные компоненты. Возможно, это уже буит какая-то типа сравнительная блокировка - юзер два часа буит разницу в новром и старом искать, потом, возможно, искать первого, кто это написал и согласовывать с ним. Живо себе это представляю. Victor Metelitsa Юзера могут быть разведены организационно. Скажем, двум юзерам дали по пачке документов, они занимаются вводом. Третий юзер занимается проверкой. Четвёртый делает отчёты за прошлый введённый месяц. Они друг другу не мешают, и блокировки не причём. Извините, подвинтесь. Вы можете организовывпать скока угодно. Однако, вопрос что должно делать приложение, если они не развелись, к примеру случайно, остается. Тем более, что я наблюдал, как правило, именно када разработчики и слыхом не слыхивали ни о каких оптимистических и писсимистических блокировках. Люди думали и до ситх пор думаут, что-то то изобрели и не в курсах, что кое-что не учли. Они полагают, раз есть термин "блокировка", то этим должна заниматься или СУБД, или выдумыввали плохие слова про юзеров и их организацию. Т.е. они типа че-то изобрели, от компонентов, которые на автомате оптимистическую включают отказались. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2012, 08:59 |
|
|
start [/forum/topic.php?all=1&fid=35&tid=1552601]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
136ms |
get tp. blocked users: |
2ms |
others: | 10ms |
total: | 230ms |
0 / 0 |