powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Отличие пессимистической и оптимистической стратегии
83 сообщений из 83, показаны все 4 страниц
Отличие пессимистической и оптимистической стратегии
    #37603994
В чем отличие пессимистической и оптимистической стратегии в блокировочнике и версионнике и в каком случае возможен и/или наиболее вероятен 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?
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604010
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
что-то в последнее время многовато появляются тем от анонимов, которые потом просто скатываются в срач. Вот и сейчас, кажется что вот снова начнется. И откуда столько троллей.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604016
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пессимистической и оптимистическ2. Версионник:
Пытаться описать работу версионника в терминах блокировочника - заведомо провальная
стратегия. Они работают совсем не так.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604017
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А полльзовался ли ТС поиском,перед тем как задать вопрос? Там столько доступной инфы, например вот кратко: http://atamanenko.blogspot.com/2009/04/blog-post_22.html
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604018
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
или википедия: http://ru.wikipedia.org/wiki/%C1%EB%EE%EA%E8%F0%EE%E2%EA%E0_(%D1%D3%C1%C4)
та мля,столько инфы. Автор, идите лучше на ... в гугл...
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604019
Ggg_oldчто-то в последнее время многовато появляются тем от анонимов, которые потом просто скатываются в срач. Вот и сейчас, кажется что вот снова начнется. И откуда столько троллей.
Не нервничай. По делу есть что сказать?
Модератор удалите оффтоп Ggg_old.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604022
Dimitry Sibiryakovпессимистической и оптимистическ2. Версионник:
Пытаться описать работу версионника в терминах блокировочника - заведомо провальная
стратегия. Они работают совсем не так.

А как он работает?
На уровне синхронизации многопоточности все реализуется и соответственно описывается через блокировки, в том числе версионники.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604031
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пессимистической и оптимистическ<...>
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.
-- создаём таблицу, вводим три строки, выполняем update одной из них (без commit'a):
C:\1INSTALL\FIREBIRD\Data>isql -n aaa.fdb
Database:  aaa.fdb
SQL> recreate table t(id int, f01 int); commit;
SQL> recreate table t(id int primary key, f01 int); commit;
SQL> create descending index t_idx on t(id); commit;
SQL> insert into t values(1,100);
SQL> insert into t values(2,200);
SQL> insert into t values(3,300);
SQL> commit;
SQL>  update t set f01=199 where id=2; 

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.
C:\1INSTALL\FIREBIRD\Data>isql -n aaa.fdb
Database:  aaa.fdb

---------- проверка доступности  записи  -----------

SQL> commit; set transaction read committed record_version;
SQL> update t set f01=201 where id=2;
^C -- срубил ввиду бесконечного ожидания

C:\1INSTALL\FIREBIRD\Data>isql -n aaa.fdb
Database:  aaa.fdb
SQL> commit; set transaction read committed no record_version;
SQL> update t set f01=201 where id=2;
^C -- срубил ввиду бесконечного ожидания

C:\1INSTALL\FIREBIRD\Data>isql -n aaa.fdb
Database:  aaa.fdb
SQL> commit; set transaction read committed record_version lock timeout 4;
SQL> update t set f01=201 where id=2;
Statement failed, SQLSTATE = 40001
lock time-out on wait transaction
-deadlock
-update conflicts with concurrent update
-concurrent transaction number is 30

SQL> commit; set transaction read committed no record_version lock timeout 4;
SQL> update t set f01=201 where id=2;
Statement failed, SQLSTATE = 40001
lock time-out on wait transaction
-deadlock

SQL> commit; set transaction snapshot lock timeout 4;
SQL> update t set f01=201 where id=2;
Statement failed, SQLSTATE = 40001
lock time-out on wait transaction
-deadlock
-update conflicts with concurrent update
-concurrent transaction number is 30

---------- проверка доступности  чтения  -----------

SQL> commit; set transaction read committed record_version lock timeout 4;
SQL> select * from t;

          ID          F01
============ ============
           1          100
           2          200
           3          300

SQL> commit; set transaction read committed  no  record_version lock timeout 4;
SQL> select * from t;

          ID          F01
============ ============
           1          100
Statement failed, SQLSTATE = 40001
lock time-out on wait transaction
-deadlock

SQL> commit; set transaction snapshot lock timeout 4;
SQL> select * from t;

          ID          F01
============ ============
           1          100
           2          200
           3          300

-- пробуем при NO record_version прочитать всё, за исключением "проблемной" записи:
SQL> commit; set transaction read committed  no  record_version lock timeout 4;
SQL> select * from t where  id<>2 ;

          ID          F01
============ ============
           1          100
Statement failed, SQLSTATE = 40001
lock time-out on wait transaction
-deadlock

-- то же самое, но используя навигацию индексу:
SQL> set plan on;
SQL> commit; set transaction read committed  no  record_version lock timeout 4;
SQL> select * from t where id<>2 order by id desc;

PLAN (T ORDER T_IDX)

          ID          F01
============ ============
           3          300
Statement failed, SQLSTATE = 40001
lock time-out on wait transaction
-deadlock
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604032
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А как он работает?На уровне синхронизации многопоточности все реализуется и соответственно описывается через
блокировки, в том числе версионники.

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

RTFM:
http://www.ibphoenix.com/resources/documents/search/doc_27
http://ibase.ru/devinfo/mga.htm
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604095
Смешались в кучу кони, люди... ((с) М.Ю. Лермонтов. Бородино)

пессимистической и оптимистическИ какой стратегии придерживаются различные СУБД: Oracle, PostgreSQL, MS SQL, Firebird?

А СУБД то здесь причем, если выбор стратегии "оптимистическая" или "пессимистичекая" лежит полностью на плечах разработчика?!

Update Conflict в блокировочнике при выбранной оптимистической стратегии, опять же, без дополнительных телодвижений со стороны разработчика не то, чтобы не разрешим самой СУБД, он ей не детектируем.

Какую задачу пытаемся решить? Обсудить как каждая из СУБД, поддерживающая версионность, детектирует и разрешает Update Conflict?
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604644
Блокировочник 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 в них.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604659
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пессимистической и оптимистическОсобенно интересует оптимистическая стратегия в версионниках и разрешение Update Conflict
в них.

А Вам не приходило в голову, что каждый сервер это делает по-разному? И даже один и тот же
- в разных ситуациях?..
Firebird, например, детектирует update conflict по наличию версии записи с номером больше
чем ожидаемый. Но никогда сама не пытается этот конфликт разрешить, честно сообщая о нём
пользователю.
Oracle - наоборот, разрешает конфликт откатывая один из запросов и пытаясь начать всё заново.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604668
Dimitry Sibiryakovпессимистической и оптимистическОсобенно интересует оптимистическая стратегия в версионниках и разрешение Update Conflict
в них.

А Вам не приходило в голову, что каждый сервер это делает по-разному? И даже один и тот же
- в разных ситуациях?..
Firebird, например, детектирует update conflict по наличию версии записи с номером больше
чем ожидаемый. Но никогда сама не пытается этот конфликт разрешить, честно сообщая о нём
пользователю.
Oracle - наоборот, разрешает конфликт откатывая один из запросов и пытаясь начать всё заново.
Так именно по этому и спрашиваю, что не знаю всех вариантов.
Т.е. Firebird при commit блокирует список всех всех прочтенных в этой транзакции записей, кстати он наверное иногда очень большой получается. Пробегает по этому списку и для каждой записи в ней смотрит последнюю версию. Ну а блокирует видимо для того, чтобы пока он это все делает не появилось новых записей, правильно?
Т.е. Firebird блокирует строки только изменяемые и только на время изменения записей и все строки во время commit?

А способы возникновения update conflict в Oracle и Firebird схожи, т.е. всегда когда другая транзакция меняет любую строчку которая читалась/менялась в нашей транзакции?
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604684
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пессимистической и оптимистическТ.е. Firebird при commit блокирует список всех всех прочтенных в этой транзакции записей

Нет, конечно. Такую глупость могут только блокировочники. Конфликт обнаруживается
непосредственно при изменении записи. Есть два номера транзакций: тот, который был прочтён
перед изменением записи и тот, который у записи на диске теперь. Не совпадают - в морг. Не
сразу, там много чего ещё наворочено типа параметров транзакций и обнаружения мёртвых
транзакций, но при нормальном течении событий - в морг.

пессимистической и оптимистическТ.е. Firebird блокирует строки только изменяемые и только на время изменения записей и все
строки во время commit?
Нет, Firebird вообще не блокирует записи (только разделяемые ресурсы, такие как буфер
страницы в кэше) и тем более - при commit. Я же, блин, выше уже дал две ссылки. Чукча не
читатель?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604703
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 подобным образом?
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604716
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пессимистической и оптимистическКстати, т.к. Firebird опирается он только на номера версий, и в нем нету блокировок, то он
не может пройти по их графу и найти deadlock,

Так и не образуется никакого дедлока при самом апдейте. Только при ожидании завершения
конкурирующей транзакции, а тут уже граф локов есть. Или таймаут ожидания (в зависимости
опять же от параметров).
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604725
Dimitry Sibiryakovпессимистической и оптимистическКстати, т.к. Firebird опирается он только на номера версий, и в нем нету блокировок, то он
не может пройти по их графу и найти deadlock,

Так и не образуется никакого дедлока при самом апдейте. Только при ожидании завершения
конкурирующей транзакции, а тут уже граф локов есть. Или таймаут ожидания (в зависимости
опять же от параметров).

Здесь я уже общий случай рассматриваю. Может быть обычный долгий "лок", а может и "дедлок", если та транзакция которую ждут решит изменить запись которую изменил предыдущий стейтмент нашей ждущей транзакции.

А вот насчет графа локов не понял. Как может существовать граф блокировок без существования самих блокировок? :)
Или имеется ввиду некий граф ожиданий друг друга транзакциями?
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604763
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пессимистической и оптимистическА вот насчет графа локов не понял. Как может существовать граф блокировок без существования самих блокировок? :) Или имеется ввиду некий граф ожиданий друг друга транзакциями?
ожидание коммита/роллбека конкурирующей транзакции реализовано через менеджер блокировок, просто уровень блокировок другой (транзакции, а не записи).
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604843
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В документацию по TOPLink/S (универсальный O/R framework для Smalltalk'ов) про их реализацию "оптимизма" рассказывалось так:

* в таблице заводится дополнительное поле version (числовое);
* обновление (TOPLink'ом) производится так:
Код: plsql
1.
2.
3.
UPDATE таблица
SET version = version + 1
WHERE (поиск-по-ключу) AND version = :считанная-нами-версия


(можно также использовать не числовую, а Timestamp'овую version)

И если этот UPDATE обновил 1 запись, то всё хорошо. А если 0, то это означает, что кто-то обновил эту запись до, и TOPLink выбрасывает исключение, и разбирайтесь с этим, как знаете (к примеру, уведомите юзера, что кто-то успел раньше).

Вот и всё. Конечно, чтобы оно работало на блокировочнике действительно "оптимистично", надо помнить, что даже чтение (обычно) накладывает блокировку. Какая блокировка и на что, каков её срок жизни - зависит от уровня изоляции (а курсор with hold и его блокировки даже переживут commit, хотя не rollback). На блокировочнике надо будет выбрать изоляцию пониже и коммититься почаще.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604872
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
поправка
Код: plsql
1.
2.
3.
UPDATE таблица
SET version = version + 1, ... прочие изменения
WHERE (поиск-по-ключу) AND version = :считанная-ранее-нами-версия
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37604926
Victor Metelitsaпоправка
Код: plsql
1.
2.
3.
UPDATE таблица
SET version = version + 1, ... прочие изменения
WHERE (поиск-по-ключу) AND version = :считанная-ранее-нами-версия


И этот Update Statment крутиться в цикле до первого успешного изменения?
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605021
Victor MetelitsaИ если этот UPDATE обновил 1 запись, то всё хорошо. А если 0, то это означает, что кто-то обновил эту запись до, и TOPLink выбрасывает исключение, и разбирайтесь с этим, как знаете (к примеру, уведомите юзера, что кто-то успел раньше).
А если UPDATE STATMENT обновляет не 1, а 10 записей, или из 10 возможных обновил только 9 это считается успешным?
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605207
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пессимистической и оптимистическVictor Metelitsaпоправка
Код: plsql
1.
2.
3.
UPDATE таблица
SET version = version + 1, ... прочие изменения
WHERE (поиск-по-ключу) AND version = :считанная-ранее-нами-версия


И этот Update Statment крутиться в цикле до первого успешного изменения?

Я уже сказал - выбрасывается исключение. Как оно будет обрабатываться - уже не забота TOPLink'а. В принципе, цикл здесь подразумевается, но со взаимодействем с пользователем.

Пользователь прочитал данные (в какой-то форме), изменил, нажал кнопку "сохранить". Выскочило исключение: "Пока, мол, вы чем-то занимались, данные уже изменились. Теперь они не такие-то, а такие-то. Хотите ли изменить их?". Пользователь, предположим, правит их, нажимает на кнопку сохранить. А ему в ответ - "ой, а эти данные опять кто-то успел изменить". И так далее. Цикл, пока сохранение не пройдёт или пользователю не надоест.

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

Если расширять пример до N записей (и надо ещё придумать, как), то только N успешно обновлённых записей может быть успехом.

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

Классический вариант, который я видел "везде" - проверить все старые значения полей.
Код: plsql
1.
2.
3.
UPDATE таблица
SET version = version + 1, ... прочие изменения
WHERE (поиск-по-ключу) AND поле1 = :старое-значение-поля1 AND ... AND полеN = :старое-значение-поляN


но вариант выше с version проще и универсальнее (LOB'ы обычно сравнить не так легко).
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605470
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaКлассический вариант, который я видел "везде" - проверить все старые значения полей.
"Классический", надеюсь, не всегда синоним слова "тупой". Корректно проверить все старые значения полей обычно немного тяжеловато, ибо во-первых, из-за null-ов, сравнение получается громоздким, во-вторых, блобы обычно немного неудобно сравнивать на равенство, в-третьих, объёмы...
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605506
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerиз-за null-ов, сравнение получается громоздкимв Firebird есть замечательная конструкция для этого: a is [not] distinct from b.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605554
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer"Классический", надеюсь, не всегда синоним слова "тупой". Корректно проверить все старые значения полей обычно немного тяжеловато, ибо во-первых, из-за null-ов, сравнение получается громоздким, во-вторых, блобы обычно немного неудобно сравнивать на равенство, в-третьих, объёмы...

Если условие во where генерирует какой-то framework (или дельфийский компонент, или подобное; заодно оно может понимать, какие поля NOT NULL, и учесть это), то за громоздкость и объёмы можно не переживать, просто не смотря лишний раз на генерируемый код. Но решение с version я только в TOPLink'е видел. (Наверное, есть и в GLORP-е, наследнике TOPLink'а, но я не интересовался).
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605651
Victor MetelitsaКлассический вариант, который я видел "везде" - проверить все старые значения полей.

How to use the timestamp column of a table for optimistic concurrency control in SQL Server
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605657
Я правильно понимаю, что в крайних случаях:
- пессимистический подход ближе к блокировочникам, есть вероятность 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
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605661
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
optimistic concurrencyVictor MetelitsaКлассический вариант, который я видел "везде" - проверить все старые значения полей.

How to use the timestamp column of a table for optimistic concurrency control in SQL Server
Ну, я и не вездесущ.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605662
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я правильно понимаюв блокировочнике MS SQL про update conflict никто и не слышал

Там у них про транзакции вообще слышал далеко не каждый второй.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605670
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я правильно понимаюЯ правильно понимаю, что в крайних случаях:
- пессимистический подход ближе к блокировочникам, есть вероятность deadlock, но не возможен update conflict
- оптимистический подход ближе к версионникам, мало вероятен(в некоторых вариантах реализации не возможен) deadlock, но появляется вероятность update conflict

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

Оптимистичный подход (наверняка нам никто не помешает) должен быть примерно одинаков и там, и там, поскольку (по возможности) избегаются блокировки. Пессимистический (нам кто-то может помешать, и мы должны это предотвратить) же требует блокировок, а потому здесь возникают нюансы.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605673
Я правильно понимаюНапример в блокировочнике MS SQL про update conflict никто и не слышал .

MS SQL уже давно не только блокировочник.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605695
неправильно понимаешьЯ правильно понимаюНапример в блокировочнике 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 или репликацией?
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605699
Victor MetelitsaЯ правильно понимаюЯ правильно понимаю, что в крайних случаях:
- пессимистический подход ближе к блокировочникам, есть вероятность deadlock, но не возможен update conflict
- оптимистический подход ближе к версионникам, мало вероятен(в некоторых вариантах реализации не возможен) deadlock, но появляется вероятность update conflict

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

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

У кого-нибудь есть ответ, уточнения или конструктивная критика такого обобщения?
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605746
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я правильно понимаюты утверждаешь что в MS SQL без использования MVC...
....есть только один уровень изоляции транзакций - Dirty Read, вследствие чего работающие с
ним люди вообще о транзакциях не думают. И таки да, на этом уровне эту ошибку получить нельзя.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605763
Dimitry SibiryakovЯ правильно понимаюты утверждаешь что в MS SQL без использования MVC...
....есть только один уровень изоляции транзакций - Dirty Read, вследствие чего работающие с
ним люди вообще о транзакциях не думают. И таки да, на этом уровне эту ошибку получить нельзя.

По моему ты единственный кто пользуется Dirty Read...
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605764
NOLOCK MS SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry SibiryakovЯ правильно понимаюты утверждаешь что в MS SQL без использования MVC...
.... есть только один уровень изоляции транзакций - Dirty Read , вследствие чего работающие с
ним люди вообще о транзакциях не думают.

Дмитрий сегодня превзошел сам себя... Браво!!!
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605795
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NOLOCK MS SQLДмитрий сегодня превзошел сам себя... Браво!!!

Ах да, я забыл "read nothing". Простая задачка: в таблице есть запись со значением поля
a=1. Одна транзакция делает update t set a=2 where a=1 и не коммитится. Какое значение
получит любая другая транзакция, пытающаяся читать это поле? Версионность отключена,
напоминаю.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605808
Dimitry SibiryakovNOLOCK MS SQLДмитрий сегодня превзошел сам себя... Браво!!!

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

У тебя в dirty read получит a=2, а у всех остальных будет ждать завершения первой транзакции и снятия X-блокировки.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605827
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну как я и сказал: read nothing.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37605925
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А причем тут блокировочник/версионник к оптимистическому/пессимистическому накладыванию блокировки?
Хотя конечно они сильно связаны, но это все-таки разные понятия, как длина и вес.
Никто вам не мешает на версионнике сделать select for update и получить пессимистическую блокировку. Надо использовать просто более подходящий инструмент для решения конкретной задачи исходя из природы ее блокировок.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606502
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пессимистической и оптимистическ,


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

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

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


На практике наблюдал отсутсвие обоих блокировок. Ну это видимо сверхоптимистичная уж не знаю что. Недостато, юзер набирал два часа, думает, что все сохранено, а оно на самом деле пропало. Када это всплывет, юзра могоут не просто обеспокоиться, но даже озаботиться. И не тока те, что набирали.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606511
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoНа практике наблюдал отсутсвие обоих блокировок. Ну это видимо сверхоптимистичная уж не
знаю что. Недостато, юзер набирал два часа, думает, что все сохранено, а оно на самом деле
пропало. Када это всплывет, юзра могоут не просто обеспокоиться, но даже озаботиться.

Не, эти тормоза не обеспокоятся, поскольку как раз их-то изменения - сохранятся.
Обеспокоиться могли бы те, кто набирал только полтора часа, поскольку именно их изменения
были затёрты теми, что набирались два часа...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606567
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 не будут использовать ни оптимистическую, ни пессимистическую блокировку, а просто, кто последний закоммитил - того и данные в базе?
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606601
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пессимистической и оптимистическПо моему под Oracle в DOA тоже нечто такое есть?

Нету. Оракул ограничен одной транзакцией на коннект.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606603
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пессимистической и оптимистическесли специальных действий не предпринимать и не использовать компоненты в которых
реализованы блокировки, то сами Oracle и Firebird не будут использовать ни
оптимистическую, ни пессимистическую блокировку, а просто, кто последний закоммитил - того
и данные в базе?

У Оракула - да. У Firebird - один из них получит ошибку, тот самый update conflict.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606609
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovНету. Оракул ограничен одной транзакцией на коннект.
Ну во-первых, это не совсем так (ну а на самом деле даже совсем не так), во-вторых, никто не требует ограничиваться одним коннектом. Вопрос только в том, что в общем нет причин так извращаться.

vadiminfoНа практике наблюдал отсутсвие обоих блокировок. Ну это видимо сверхоптимистичная уж не знаю что.
Не обязательно. Есть третий и вполне правильный вариант - доступность операции по бизнес-логике.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606630
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 или только через компоненты доступа?
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606641
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пессимистической и оптимистическНу так 2 конекта - 2 транзакции (возможно с разными уровнями изоляции)

И вот оно: лицензионное ограничение количества пользовательских сессий.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606646
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пессимистической и оптимистическНе, ну потерять данные одной из транзакции причем без осознания этого тоже не очень вариант.
Это не имеет ни малейшего отношения к количеству коннектов и транзакций.

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

На уровне СУБД пожалуй что в любой СУБД такой режим включается через serializable. Впрочем, не уверен, что стал бы рекомендовать такое решение. Оптимистическую блокировку в Oracle правильнее всего, наверное, делать через ORA_ROWSCN - это псевдоколонка таблицы, показывающая когда (каким номером транзакции) в последний раз модифицировалась указанная запись.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606648
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakovпессимистической и оптимистическНу так 2 конекта - 2 транзакции (возможно с разными уровнями изоляции)

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

А поподробнее? А то, похоже, я счастливо отстал от лицензионной политики.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606659
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerА поподробнее? А то, похоже, я счастливо отстал от лицензионной политики.

Я тоже, но в семёрке было ограничение на количество сессий, которое, впрочем,
увеличивалось в конфиге.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606664
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovЯ тоже, но в семёрке было ограничение на количество сессий, которое, впрочем, увеличивалось в конфиге.

Ну Вы и вспомнили. Во времена семёрки Firebird и оператора SELECT-то выполнять не умел
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606669
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoПиссимистическая блокировка - конфиликты ожидаются частыми. Тогда предпочтительнее сессиям планирующим менять одну и ту же запись, начинать делать это убедившись, что никто этим еще не начал заниматься. В Оракле есть для этого в SELECT конструкция For Update.
Клиентская прога предназнченная для редактиравования, выполнит не просто SELECT а SELECT For Update. В этом случе любой другой запрос с For Update, а это все , в данном приложении, кто тоже собирается редактировать (тем более обычно в кленте одно окно для редактирования одних и тех же структур данных), и потому тоже юзают SELECT For Update, не смогут выполнить такой запрос, пока первая не разблокирует заблокированный ресурс. Чтение - просто SELECT данных до начала изменений доступно (но это другое окно в приложении).
Недостаток: юзера с помощью окон для редактирования в таком приложении не смогут даже прочитать заблокирование. Тока с окнами для чтений.

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


Жуткая кривота и то, и другое. В первом случае существует select for update nowait, и приличное приложение немедленно получит ошибку, если ему заблокировать не удалось. В таком случае оно может перечитать данные простым select'ом. Но это просто неудобства. Во втором случае это натуральный ужас. Почему работа по редактированию пропала? Когда знаем и текущие значения в базе, и значения, введённые юзером, почему их ему не показать и то, и то одновременно, и не помочь?

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

Юзера могут быть разведены организационно. Скажем, двум юзерам дали по пачке документов, они занимаются вводом. Третий юзер занимается проверкой. Четвёртый делает отчёты за прошлый введённый месяц. Они друг другу не мешают, и блокировки не причём.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606670
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerВо времена семёрки Firebird и оператора SELECT-то выполнять не умел

Зато это умел Interbase.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606675
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakovпессимистической и оптимистическНу так 2 конекта - 2 транзакции (возможно с разными уровнями изоляции)

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

А это где? Оракля и DB2 лицензируют поядерно/попроцессорно/посокетно или же как для named users, у каждого из которых хоть по 10 коннектов... а хоть и ни одного коннекта (т.е., работает через connection pooling) - неважно, он всё равно за 1 сосчитается.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606698
softwarerпессимистической и оптимистическНе, ну потерять данные одной из транзакции причем без осознания этого тоже не очень вариант.
Это не имеет ни малейшего отношения к количеству коннектов и транзакций.
Видимо я не совсем понял, что вы имелли ввиду под "нет причин так извращаться" - про два коннекта?
softwarerDimitry SibiryakovНету. Оракул ограничен одной транзакцией на коннект.
Ну во-первых, это не совсем так (ну а на самом деле даже совсем не так), во-вторых, никто не требует ограничиваться одним коннектом. Вопрос только в том, что в общем нет причин так извращаться.
1. нет причин одновременно просматривать и редактировать? т.е. советуете использовать пессиместическую блокировку с одним коннектом.
2. нет причин использовать пессиместическую блокировку? т.е. советуете использовать оптимистическую блокировку и вероятность перенаобра заново данных.
3. нет причин использовать ни пессиместическую, ни оптимистическую блокировку? и есть вероятность потерять данные.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606700
пессимистической и оптимистическА на уровне СУБД в Oracle можно "включить" оптимистическую блокировку по аналогии с Firebird или только через компоненты доступа?
Я не очень понял Ваше противопоставление.... то, что включается через фибплюсы или аналогичные специальные меры на клиенте, не кажется мне включаемым "на уровне СУБД".

На уровне СУБД пожалуй что в любой СУБД такой режим включается через serializable. Впрочем, не уверен, что стал бы рекомендовать такое решение. Оптимистическую блокировку в Oracle правильнее всего, наверное, делать через ORA_ROWSCN - это псевдоколонка таблицы, показывающая когда (каким номером транзакции) в последний раз модифицировалась указанная запись.[/quot]
Не, имеется ввиду, как включить в Oracle то, что работает в Firebird по умолчанию?
А именно из цитаты выше:
Dimitry Sibiryakovпессимистической и оптимистическесли специальных действий не предпринимать и не использовать компоненты в которых
реализованы блокировки, то сами Oracle и Firebird не будут использовать ни
оптимистическую, ни пессимистическую блокировку, а просто, кто последний закоммитил - того
и данные в базе?

У Оракула - да. У Firebird - один из них получит ошибку, тот самый update conflict.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606712
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пессимистической и оптимистическВидимо я не совсем понял, что вы имелли ввиду под "нет причин так извращаться" - про два коннекта?
Про две транзакции.

пессимистической и оптимистическ1. нет причин одновременно просматривать и редактировать? т.е. советуете использовать пессиместическую блокировку с одним коннектом. 2. нет причин использовать пессиместическую блокировку? т.е. советуете использовать оптимистическую блокировку и вероятность перенаобра заново данных. 3. нет причин использовать ни пессиместическую, ни оптимистическую блокировку? и есть вероятность потерять данные.
Если я правильно понимаю, Вы сваливаете в одну кучу совсем разные вещи. Подумайте о том, что блокировки предназначены для регулирования доступа к данным со стороны разных пользователей, и уже поэтому не имеют прямой связи с вопросом "сколько соединений и транзакций должно использовать приложение, запущенное для конкретного пользователя".

Речь же идёт ровно об одном: фибплюсовская схема предназначена для борьбы с архитектурой update conflict. В оракле такой борьбы не требуется, соответственно не требуется её повторять. Технически то же самое делается в оракле в рамках одного соединения, но поступают так редко, ибо незачем.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606728
softwarerРечь же идёт ровно об одном: фибплюсовская схема предназначена для борьбы с архитектурой update conflict. В оракле такой борьбы не требуется , соответственно не требуется её повторять. Технически то же самое делается в оракле в рамках одного соединения, но поступают так редко, ибо незачем.
А в Оракле её нету потому, что данные просто перезаписываются последней закоммитившейся транзакцией или потому, что обновление повотряется автоматически до тех пор пока не пройдет успешно?
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606736
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пессимистической и оптимистическА в Оракле её нету потому, что данные просто перезаписываются последней закоммитившейся транзакцией или потому, что обновление повотряется автоматически до тех пор пока не пройдет успешно?
Скорее первое, чем второе. Как, собственно, и в фибплюсовских приложениях. "Обновление повторяется автоматически" - это похоже на пересказ "слышал звон" так называемых оракловых мини-откатов, которые могут возникать, если несколько пользователей пытаются одновременно обновлять частично пересекающиеся множества строк.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606738
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
один дурачек (Дмитрий) ерунду спорол, а вы уши развесили


что в оракле, что в фаирберд пишушие транзакции идентично расставляют блокировки, Таблойд еще на первой странице все разжувал кодом:

http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=908100&msg=11864628
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606755
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пессимистической и оптимистическНе, имеется ввиду, как включить в Oracle то, что
работает в Firebird по умолчанию?
В Firebird по умолчанию работает TIL snapshot, которого в Оракуле просто нет.

Yo.!Таблойд еще на первой странице все разжувал кодом:

Таблоид кодом разжевал крайний случай, который ни один вменяемый разработчик использовать
не станет.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606767
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry SibiryakovТаблоид кодом разжевал крайний случай, который ни один вменяемый разработчик использовать
не станет.

крайний случай - это ты. закусывай уже, праздники кончились. глядишь и снепшот найдется в оракле. хотя учитывая, что случай крайний - не факт, что у тебя найдется.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606783
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!глядишь и снепшот найдется в оракле
Как же, как же, помню этот ваш смешной serializable с версионностью уровня страницы. Да и
запрет на чтение изменяемой таблицы тоже найдётся...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606786
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakovserializable с версионностью уровня страницы

вот по тому я и говорю - дурачка не слушать
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606788
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!вот по тому я и говорю - дурачка не слушать

Нет, я конечно, помню, что существует танец с бубном, от которого и без того
невысокое быстродействие
падает ещё ниже плинтуса...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606798
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry SibiryakovНет, я конечно, помню, что существует танец с бубном, от которого и без того
невысокое быстродействие
падает ещё ниже плинтуса...

вот потому Yo! и зарабатывает себе и на икорку, что у всяких дурачков то снепшот потерялся, то что-то падает
и это правильно
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606814
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
 SESSION #1 
SQL> conn hr/hr@xe
Connected.

create table tmpxxx(id int primary key, f01 int, f02 int, constraint unqxxx unique(f01,f02));
SQL> insert into tmpxxx select 1,10,null from dual union all select 2,10,10 from dual;

2 rows created.

Elapsed: 00:00:00.03
SQL> commit;

Commit complete.

Elapsed: 00:00:00.00
SQL> update tmpxxx set f01=null where id=2;

1 row updated.

Elapsed: 00:00:00.00

 SESSION #2 
SQL> conn hr/hr@xe
Connected.
SQL> insert into tmpxxx values(3,null,10);
-- курим бамбук... :-/
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606850
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЧто-то мне пока не бросилось в глаза... я могу ошибаться, но:
На очень беглый взгляд это известная багофича старых версий "программист забыл создать индекс на внешний ключ".
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606853
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хотя стоп, он же не внешний. Просто делаете вставку дублирующихся значений. Да, есть такая особенность. Версионная, я бы сказал
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606864
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Таблоид,

не понял примера. что ФБ позволит вставить третью запись не смотря на констреинт ?
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606879
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!не понял примера. что ФБ позволит вставить третью запись не смотря на констреинт ?
Ну а почему нет? Оракл, собственно, тоже вроде позволит, если сделать констрейнт отложенным.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606889
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!ФБ позволит вставить третью запись не смотря на констреинт ?Нет. Не позволит.
Второй сеанс при указании wait (default) будет также ждать до посинения, при указании no wait получит сразу же шваброй:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
SQL> set transaction snapshot  no  wait;
SQL> insert into tmpxxx values(3,null,10);
Statement failed, SQLSTATE = 23000
violation of PRIMARY or UNIQUE KEY constraint "INTEG_4" on table "TMPXXX"
SQL> rollback; set transaction read committed  no  wait;
SQL> insert into tmpxxx values(3,null,10);
Statement failed, SQLSTATE = 23000
violation of PRIMARY or UNIQUE KEY constraint "INTEG_4" on table "TMPXXX"
А при указани lock timeout NN получит облом через NN секунд (причем это число не обязано быть литералом - его можно и в кач-ве аргумента передать в ХП):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
SQL> rollback; set transaction read committed  lock timeout 5 ;
SQL> select current_timestamp from rdb$database; insert into tmpxxx values(3,null,10); select current_timestamp fro
m rdb$database;

        CURRENT_TIMESTAMP
=========================
2012-01-09 22:46:17.0150

Statement failed, SQLSTATE = 23000
violation of PRIMARY or UNIQUE KEY constraint "INTEG_4" on table "TMPXXX"

        CURRENT_TIMESTAMP
=========================
2012-01-09 22:46:22.0150
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606898
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ТаблоидНет. Не позволит.
Второй сеанс при указании wait (default) будет также ждать до посинения
ну так вроде идентично ораклу ...
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606950
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!ну так вроде идентично ораклу ...Это только при задании параметра wait.
Меня интересует (не праздно, причём), как сделать в Oracle немедленную, а еще лучше - с назначаемым таймаутом, реакцию для сеанса номер 2, который пытается выполнить изменение, приводящее к дублю.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606983
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидМеня интересует как сделать в Oracle
А никак, обломись. Впрочем Александр Рындин что-то говорил про improvement request-ы,
которые теоретически в контору Ларри можно посылать... Может, версии к двадцатой, они его
и рассмотрят...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606989
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ТаблоидЭто только при задании параметра wait.
Меня интересует (не праздно, причём), как сделать в Oracle немедленную, а еще лучше - с назначаемым таймаутом, реакцию для сеанса номер 2, который пытается выполнить изменение, приводящее к дублю.
хрен знает, я по части изврата не самый крупный специалист. у меня на ожидание юзерского инпута строгое табу, потому изврата не требуется.
вообще в оракле есть конструкция select .. for update wait 5; (или nowait) для таких случаев, но тут наверно не подойдет. тут вероятно можно извратиться через merge
типа merge ... then matched update ... where 1=2 then not matced insert ...
т.е. если запись есть апдейтим 0 строк, но я бы все таки советовал в консерватории, что-то менять.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606992
Dimitry SibiryakovТаблоидМеня интересует как сделать в Oracle
А никак, обломись. Впрочем Александр Рындин что-то говорил про improvement request-ы,
которые теоретически в контору Ларри можно посылать... Может, версии к двадцатой, они его
и рассмотрят...

А чего в контору слать, можно непосредственно "Ларри "слать. В смысле ему, а не его ;)
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37606995
Табу
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Yo.!у меня на ожидание юзерского инпута строгое табу, потому изврата не требуется Табу, никаких инсертов от пользователей?
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37607004
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ТабуYo.!у меня на ожидание юзерского инпута строгое табу, потому изврата не требуется Табу, никаких инсертов от пользователей?
если не доходит с первого раза попробуй прочесть еще раз. тут извени, уж разжевывать не буду ...
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37607026
Табу
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Yo.!Табупропущено...
Табу, никаких инсертов от пользователей?
если не доходит с первого раза попробуй прочесть еще раз. тут извени, уж разжевывать не буду ...Какое строгое табу, даже говорить на эту тему не осмеливаешься.
...
Рейтинг: 0 / 0
Отличие пессимистической и оптимистической стратегии
    #37607120
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Metelitsa
Жуткая кривота и то, и другое. В первом случае существует select for update nowait, и приличное приложение немедленно получит ошибку, если ему заблокировать не удалось. В таком случае оно может перечитать данные простым select'ом. Но это просто неудобства. Во втором случае это натуральный ужас. Почему работа по редактированию пропала? Когда знаем и текущие значения в базе, и значения, введённые юзером, почему их ему не показать и то, и то одновременно, и не помочь?

Я пытался концепцию пояснить и намеренно уклонялся от деталей. Тока для иллюстрации.
nowait - опция конструкции for update. В моем тексте, так как я не сказал, что вторая непременно зависнет пока первая не разблокирует (for update без nowait). Это уже кто какой сценарий придумает в зависмости от своей специфики требований. Второй селект - тем более детали конкретных сценариев, но я вроде писал что читать, т.е. простой select канает в Оракле, потому не отрицал этого. Так что не понял Вашу мыстль. Я не пытался написать сценарий на все случаи, и не считаю что он должент быть обязательно один.
Т.е. главное, что окно для редактирования (а не любое) не сможет прочитать (хоть с nowait хоть без поскоку есть for update) раз разработчик решил юзать писсиместическую блокировку. Нет он, конечно, может в слкучае если не проканает for update, выполнить просто select в том же окне, но написать что редпактирование не возмрожно, но это уже излишние дополнения к конценпции.

Что до второго, то не знаю, почему, но пропадает на практике из того что я видел. Ну если Вы юзаете стандартные средства. Про Дельфи писал. Ну у Аксцесса есть, наскока помню. Пропадает.
Ну потому и термин оптимистическая, что это не часто. Ну если придумаете как сохранить,то наздоровье. Но думау, это дополнительные усилия, раз на них не пошли стандартные компоненты. Возможно, это уже буит какая-то типа сравнительная блокировка - юзер два часа буит разницу в новром и старом искать, потом, возможно, искать первого, кто это написал и согласовывать с ним. Живо себе это представляю.

Victor Metelitsa
Юзера могут быть разведены организационно. Скажем, двум юзерам дали по пачке документов, они занимаются вводом. Третий юзер занимается проверкой. Четвёртый делает отчёты за прошлый введённый месяц. Они друг другу не мешают, и блокировки не причём.

Извините, подвинтесь. Вы можете организовывпать скока угодно. Однако, вопрос что должно делать приложение, если они не развелись, к примеру случайно, остается. Тем более, что я наблюдал, как правило, именно када разработчики и слыхом не слыхивали ни о каких оптимистических и писсимистических блокировках. Люди думали и до ситх пор думаут, что-то то изобрели и не в курсах, что кое-что не учли. Они полагают, раз есть термин "блокировка", то этим должна заниматься или СУБД, или выдумыввали плохие слова про юзеров и их организацию. Т.е. они типа че-то изобрели, от компонентов, которые на автомате оптимистическую включают отказались.
...
Рейтинг: 0 / 0
83 сообщений из 83, показаны все 4 страниц
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Отличие пессимистической и оптимистической стратегии
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]