Проблемка с UPDATE двух таблиц.

[Лексеич]

Проблемка с UPDATE двух таблиц.

Ситация следующая:

Есть набор "объектов" (не путать с ООП , имеется ввиду набор данных), занесенных в базу. Когда юзверь совершает некие операции с этим набором в таблицу Users прописывается статус и unixtime юзверю, что он работает с объектом. После этого в таблицу obj_data прописывается следующее: work_user=work_user+1. Т.е. это поле показывает сколько юзеров работает с этим объектом.

По тайм-ауту юзеру выставляется статус, что он не работает с объектом. После этого в obj_data пишется work_user=work_user-1. Так вод проблемка в том, что после апдэйта юзера, апдэйт work_user'a не всегда срабатывает... т.е. имеется несоответствиее юзеров, работающих с объектом (из таблицы Users) и значением поля work_user.

Уф.. надеюсь понятно изложил. В чем может быть проблема ума не приложу.

 

[DiMA]

Ну, здесь проблема явно не связанная с трудностями в SQL или UPDATE. Думай над логикой своей софтины.

 

[Лексеич]

DiMA
ну да... раз не sql значит логика. ок. спсб.

з.ы. просто интересно, два запроса идут подряд, без всяких условий... первый выполняется, а второй из десяти раз но один раз не проапдэйтит..

 

[predator]

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

во каких я словей ввернул!!! ; )

 

[DiMA]

Дык у него это глючит, видимо, еще на стадии тестирования. Т.е. нагрузок нет и вероятность параллельного исполнения нулевая. А лочить конечно надо, но только если "надо" и так, чтобы внутри локак как можно меньше работы и запросов было.

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

 

[Лексеич]

DiMA
вероятность параллельного использования не нулевая, т.к. тестится уже в онлайне....

Если можно, скажи где почитать про "лочить" и т.д.

Всё, нашел материал. Спасибо.

-~{}~ 19.05.05 14:21:

predator был прав. Проблема была именно в параллельном исполнении одного скрипта. Получиилось обойтись без ЛОКОВ, грузящих сервак. Сделал следующее:
При начале обработки проверяю флаг в специально созданной "системной" таблице. Если он не равен 1, то пишу туда 1 и исполняю скрипт. По окончании пишу туда ноль. Пока не глючит. Хех, просматривается аналогия с защитой от двойного клика по сабмиту.. Но всеравно, спасибо за помощь, ребята.

 

[camka]

А насколько будет велика вероятность рассинхронизации (и будет ли вообще онаиметь место), если сделать обновление обоих таблиц одним запросом?
[sql]
update t1, t2 set t1.tmstmp=now(), t2.work_user=t2.work_user+1 where t1.id=t2.t1_id and t1.id=$ID;
[/sql]

 

[Лексеич]

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

 

[camka]

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

user_id, object_id, datetime, is_active

И таблицы пользователей и объектов не будут заполняться неотносящейся к сущностям информацией.

 

[Лексеич]

Автор оригинала: camka
Еще как вариант - создать дополнительную таблицу связей пользователей и объектов и создавать записи там, когда пользователь работает с объектом, и удалять по таймау, или же помечать как устаревшие

собственно, пока так и сделал.