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

Откуда: 127.0.0.1
Сообщений: 67534
Блог
Dimitry Sibiryakov
пессимистической и оптимистическ
Ну так 2 конекта - 2 транзакции (возможно с разными уровнями изоляции)

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

А поподробнее? А то, похоже, я счастливо отстал от лицензионной политики.
9 янв 12, 18:02    [11874865]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

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

softwarer
А поподробнее? А то, похоже, я счастливо отстал от лицензионной политики.

Я тоже, но в семёрке было ограничение на количество сессий, которое, впрочем,
увеличивалось в конфиге.

Posted via ActualForum NNTP Server 1.5

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

Откуда: 127.0.0.1
Сообщений: 67534
Блог
Dimitry Sibiryakov
Я тоже, но в семёрке было ограничение на количество сессий, которое, впрочем, увеличивалось в конфиге.

Ну Вы и вспомнили. Во времена семёрки Firebird и оператора SELECT-то выполнять не умел
9 янв 12, 18:14    [11874927]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Victor Metelitsa
Member

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

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


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

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


Юзера могут быть разведены организационно. Скажем, двум юзерам дали по пачке документов, они занимаются вводом. Третий юзер занимается проверкой. Четвёртый делает отчёты за прошлый введённый месяц. Они друг другу не мешают, и блокировки не причём.
9 янв 12, 18:15    [11874940]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

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

softwarer
Во времена семёрки Firebird и оператора SELECT-то выполнять не умел

Зато это умел Interbase.

Posted via ActualForum NNTP Server 1.5

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

Откуда: Тюмень
Сообщений: 2559
Dimitry Sibiryakov
пессимистической и оптимистическ
Ну так 2 конекта - 2 транзакции (возможно с разными уровнями изоляции)

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

А это где? Оракля и DB2 лицензируют поядерно/попроцессорно/посокетно или же как для named users, у каждого из которых хоть по 10 коннектов... а хоть и ни одного коннекта (т.е., работает через connection pooling) - неважно, он всё равно за 1 сосчитается.
9 янв 12, 18:20    [11874971]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
пессимистической и оптимистическ
Guest
softwarer
пессимистической и оптимистическ
Не, ну потерять данные одной из транзакции причем без осознания этого тоже не очень вариант.

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

Видимо я не совсем понял, что вы имелли ввиду под "нет причин так извращаться" - про два коннекта?
softwarer
Dimitry Sibiryakov
Нету. Оракул ограничен одной транзакцией на коннект.

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

1. нет причин одновременно просматривать и редактировать? т.е. советуете использовать пессиместическую блокировку с одним коннектом.
2. нет причин использовать пессиместическую блокировку? т.е. советуете использовать оптимистическую блокировку и вероятность перенаобра заново данных.
3. нет причин использовать ни пессиместическую, ни оптимистическую блокировку? и есть вероятность потерять данные.
9 янв 12, 18:46    [11875112]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
пессимистической и оптимистическ
Guest
пессимистической и оптимистическ
А на уровне СУБД в Oracle можно "включить" оптимистическую блокировку по аналогии с Firebird или только через компоненты доступа?

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

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

У Оракула - да. У Firebird - один из них получит ошибку, тот самый update conflict.
9 янв 12, 18:46    [11875115]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
пессимистической и оптимистическ
Видимо я не совсем понял, что вы имелли ввиду под "нет причин так извращаться" - про два коннекта?

Про две транзакции.

пессимистической и оптимистическ
1. нет причин одновременно просматривать и редактировать? т.е. советуете использовать пессиместическую блокировку с одним коннектом. 2. нет причин использовать пессиместическую блокировку? т.е. советуете использовать оптимистическую блокировку и вероятность перенаобра заново данных. 3. нет причин использовать ни пессиместическую, ни оптимистическую блокировку? и есть вероятность потерять данные.

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

Речь же идёт ровно об одном: фибплюсовская схема предназначена для борьбы с архитектурой update conflict. В оракле такой борьбы не требуется, соответственно не требуется её повторять. Технически то же самое делается в оракле в рамках одного соединения, но поступают так редко, ибо незачем.
9 янв 12, 19:01    [11875183]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
пессимистической и оптимистическ
Guest
softwarer
Речь же идёт ровно об одном: фибплюсовская схема предназначена для борьбы с архитектурой update conflict. В оракле такой борьбы не требуется, соответственно не требуется её повторять. Технически то же самое делается в оракле в рамках одного соединения, но поступают так редко, ибо незачем.

А в Оракле её нету потому, что данные просто перезаписываются последней закоммитившейся транзакцией или потому, что обновление повотряется автоматически до тех пор пока не пройдет успешно?
9 янв 12, 19:14    [11875248]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
пессимистической и оптимистическ
А в Оракле её нету потому, что данные просто перезаписываются последней закоммитившейся транзакцией или потому, что обновление повотряется автоматически до тех пор пока не пройдет успешно?

Скорее первое, чем второе. Как, собственно, и в фибплюсовских приложениях. "Обновление повторяется автоматически" - это похоже на пересказ "слышал звон" так называемых оракловых мини-откатов, которые могут возникать, если несколько пользователей пытаются одновременно обновлять частично пересекающиеся множества строк.
9 янв 12, 19:25    [11875286]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Yo.!
Guest
один дурачек (Дмитрий) ерунду спорол, а вы уши развесили


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

https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=908100&msg=11864628
9 янв 12, 19:28    [11875300]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

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

пессимистической и оптимистическ
Не, имеется ввиду, как включить в Oracle то, что
работает в Firebird по умолчанию?

В Firebird по умолчанию работает TIL snapshot, которого в Оракуле просто нет.

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

Таблоид кодом разжевал крайний случай, который ни один вменяемый разработчик использовать
не станет.

Posted via ActualForum NNTP Server 1.5

9 янв 12, 19:51    [11875370]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Yo.!
Guest
Dimitry Sibiryakov
Таблоид кодом разжевал крайний случай, который ни один вменяемый разработчик использовать
не станет.

крайний случай - это ты. закусывай уже, праздники кончились. глядишь и снепшот найдется в оракле. хотя учитывая, что случай крайний - не факт, что у тебя найдется.
9 янв 12, 20:09    [11875414]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

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

Yo.!
глядишь и снепшот найдется в оракле

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

Posted via ActualForum NNTP Server 1.5

9 янв 12, 20:35    [11875469]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Yo.!
Guest
Dimitry Sibiryakov
serializable с версионностью уровня страницы

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

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

Yo.!
вот по тому я и говорю - дурачка не слушать

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

Posted via ActualForum NNTP Server 1.5

9 янв 12, 20:48    [11875493]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Yo.!
Guest
Dimitry Sibiryakov
Нет, я конечно, помню, что существует танец с бубном, от которого и без того
невысокое быстродействие
падает ещё ниже плинтуса...

вот потому Yo! и зарабатывает себе и на икорку, что у всяких дурачков то снепшот потерялся, то что-то падает
и это правильно
9 янв 12, 21:02    [11875544]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
Yo.!
что в оракле, что в фаирберд пишушие транзакции идентично расставляют блокировки,
Что-то мне пока не бросилось в глаза... я могу ошибаться, но:

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);
-- курим бамбук... :-/
9 янв 12, 21:23    [11875632]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
Таблоид
Что-то мне пока не бросилось в глаза... я могу ошибаться, но:

На очень беглый взгляд это известная багофича старых версий "программист забыл создать индекс на внешний ключ".
9 янв 12, 21:59    [11875703]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
Хотя стоп, он же не внешний. Просто делаете вставку дублирующихся значений. Да, есть такая особенность. Версионная, я бы сказал
9 янв 12, 22:05    [11875716]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Yo.!
Guest
Таблоид,

не понял примера. что ФБ позволит вставить третью запись не смотря на констреинт ?
9 янв 12, 22:15    [11875751]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
Yo.!
не понял примера. что ФБ позволит вставить третью запись не смотря на констреинт ?

Ну а почему нет? Оракл, собственно, тоже вроде позволит, если сделать констрейнт отложенным.
9 янв 12, 22:29    [11875783]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
Yo.!
ФБ позволит вставить третью запись не смотря на констреинт ?
Нет. Не позволит.
Второй сеанс при указании wait (default) будет также ждать до посинения, при указании no wait получит сразу же шваброй:
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 секунд (причем это число не обязано быть литералом - его можно и в кач-ве аргумента передать в ХП):
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
9 янв 12, 22:48    [11875852]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Yo.!
Guest
Таблоид
Нет. Не позволит.
Второй сеанс при указании wait (default) будет также ждать до посинения

ну так вроде идентично ораклу ...
9 янв 12, 22:57    [11875903]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить