Транзакция на обновление записи

← →
RomanH © (2006-10-31 12:20) [0]

Мастера, и снова я к Вам, за вашей помощью. Существует таблица, в которой находится список и колличество товара для продажи клиентам. При выборе какой нибудь записи, появляется модальное окно для выбора колличества товара(т.е. у пользователя А стартует транзакция с параметрами {write,concurrency,nowait}).После выбора колличества, создаю накладную, а в основном списке уменьшаю колличество, подтверждаю транзакцию.В это же время пользователь B тоже хочет продать этот же товар но возникает ошибка deadlock update conflict.Помогите пожайлусто, как сделать чтобы два пользователя могли продавать(в моем случае редактировать т.е. уменьшать колличество в основной таблице)

← →
unknown © (2006-10-31 12:41) [1]

> RomanH © (31.10.06 12:20)
> модальное окно для выбора колличества товара(т.е. у пользователя А стартует транзакция

Вот тут неправильно.
В таких случаях лучше всего сделать так:
1) Показываем форму, юзер заполняет на форме поля
2) Формируем запрос, далее starttransaction; execsql; commit;
Можно в принципе и уровень изоляции поменять.

← →
RomanH © (2006-10-31 12:41) [2]

Мастера ну вот получилось, с такими параметрами
read_committed
rec_version
nowait
Но так как я начинающий все таки хотелось чтобы вы меня поправили.
Read_committed-Возможность читать подтвержденные данные других транзакций.Вопрос а где жевозможность писать поддвержденные данные.

← →
jack128 © (2006-10-31 12:50) [3]

на ib/fb с транзакциями обычно работают так:
все чтение один через транзакцию с параметрами
read_committed
rec_version
nowait
read
Обычно она открывается при старте приложения и закрывается при его завершении.

для записи используется __максимально короткая__ транзакция
write
read_committed
rec_version
nowait
открыл эту транзакцию, выполнил запрос, тут же закрыл её. Никаких открытий write транзакций при открытии модального диалога быть не должно!!!

При такой работе update conflict практически невозможен.

RomanH © (31.10.06 12:41) [2]
а где жевозможность писать поддвержденные данные.
не очень понятно, что имеется в виду?

← →
RomanH © (2006-10-31 13:04) [4]

> jack128 ©

Выше указанный код :
write
read_committed
rec_version
nowait мне все объяснил я увидел слово write.
Хотя и без параметра write работает, почему? мы же только считываем подтвержденные записи(read_committed).Объсните мнe пожайлусто
.

← →
Desdechado © (2006-10-31 13:10) [5]

читать доки и ibase.ru до прояснения

> а где жевозможность писать поддвержденные данные
Орех!
Как ты себе представляешь запись неподтвержденных данных?

ЗЫ про дедлоки тоже читать там же
они возникают, когда в разных режимах пытаешься писать данные в разном порядке, что вызывает конфликт при использовании этих режимов в разных подключениях

← →
RomanH © (2006-10-31 13:20) [6]

Ну вот один из моих основных преподавателей Desdechado (это не лесть-это правда) отправляет меня на IBase.ru/Хотя там я уже можно сказать прописан, даже скачал весь сайт.
Ну ладно буду читать до прояснения(сколько же времени это займет).
Может существует наработанная практика по работе с транзакциями. Спасибо всем.

← →
Sergey13 © (2006-10-31 13:35) [7]

> Может существует наработанная практика по работе с транзакциями.

А чем [1] + [3] не устраивает?

← →
Anatoly Podgoretsky © (2006-10-31 15:34) [8]

> RomanH (31.10.2006 13:20:06) [6]

> отправляет меня на меня на IBase.ru

С каких пор отправление в правильном направлении стало обидой?

← →
Johnmen © (2006-10-31 15:39) [9]

> RomanH © (31.10.06 13:20) [6]
> ...даже скачал весь сайт.

Судя по вопросу, осталось прочитать. Хотя бы основы.

← →
RomanH © (2006-10-31 16:02) [10]

> Anatoly Podgoretsky ©

Да нет это не обида. Просто очень хочется такую информацию чтобы было понятно все о транзакциях, хотя Дмитрий Кузьменко(ibase.ru) и описывает подробно о транзакциях все же некоторые аспекты непонятны. Наверное понимание прийдет с опытом.Сегодня транзакция на обновление записей,завтра на чтение. Надеюсь этот форум мне всегда поможет.

> Sergey13 © (31.10.06 13:35) [7]

Да как раз [1]+[3] и разрешили мою проблему сегодня.

Всем спасибо

← →
Дмитрий Белькевич © (2006-11-01 03:09) [11]

>на ib/fb с транзакциями обычно работают так:
все чтение один через транзакцию с параметрами
Обычно она открывается при старте приложения и закрывается при его завершении.
для записи используется __максимально короткая__ транзакция
При такой работе update conflict практически невозможен.

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

← →
atruhin © (2006-11-01 12:38) [12]

> После выбора колличества, создаю накладную, а в основном
> списке уменьшаю колличество, подтверждаю транзакцию.В это
> же время пользователь B тоже хочет продать этот же товар
> но возникает ошибка deadlock update conflict.

Тут еще и методологически не правильно, представь, пользователь выбрал товар, ту уменьшил его кол-во на складе (основной список),
а дальше произошел сбой сети, или компьютер вырубили. Что будет, со склада ты товар списал, а куда?
Изучай теорию построения учетных систем. Статей море.

← →
PEAKTOP © (2006-11-01 13:50) [13]

Я обычно в таких случаях в журнале документов (таблице, где хранится "шапочная" часть документа) добавляю поле FLAG_COMMIT. Пользователи могут колотить накладные хоть до посинения, фактическое списание товара происходит в момент проведенения (установки FLAG_COMMIT= 1), а возврат "на место" в момент распроведения (установки FLAG_COMMIT= 0), причем все происходит в триггерах на BEFORE UPDATE.
Таким образом, если кто-то провел накладную на доли секунды раньше, то второй при недостатке товара получит облом при проведении. А там пусть сами (пользователи) между собой разбираются, кому товар нужнее.
Таким же образом решается проблема, когда нужно наколотить накладную "в прок". Т.е. клиент по телефону заказывает товар, а оплачивать/получать придет через час. И по бизнес логике предприятия, отпускать товар нужно в момент оплаты/получения. Если его к тому моменту не оказалось в наличии, то уж извините, не успели.

← →
atruhin © (2006-11-01 14:58) [14]

> [13] PEAKTOP © (01.11.06 13:50)

Ну это обычная практика, только у нас например, > добавляю поле FLAG_COMMIT
может иметь значения:
0 - удален
1 - в работе (не закончен)
2 - документ набран (готов)
3 - проведен
4 - закрыт (гл. бухгатер, руководитьель закрыл период, ни кто не может изменить.

> atruhin (01.11.2006 14:58:14) [14]

Если сделано на уровне триггеров/процедур то нормально.

> Если сделано на уровне триггеров/процедур то нормально.

Ну а как же еще? Именно об этом я и написал автору 4-мя постами выше.

> atruhin (01.11.2006 15:22:16) [16]

Может быть, но это 4 выше и возможно не к этому случаю.
Если подобное не сделано указаными способами, то кто мешает мне
альтернативными методами изменить запись в обход.

> [17] Anatoly Podgoretsky © (01.11.06 15:28)
то кто мешает мне альтернативными методами изменить запись в обход

У нас ни кто не помешает, при наличии пароля владельца БД или SYSDBA. А для остальных, модифицируемые представления,
с соответствующими тригерами.

> atruhin (01.11.2006 15:34:18) [18]

А у нас помешает даже при наличии этого пароля.

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

Транзакция на обновление записи Найти похожие ветки