Всем добрый день!

Плиз, не бейте ногами, потому что помимо освоения базы решаю еще тучу задачек.
Столкнулся вот с чем. В многопотоковом приложении Linux сделал автоматическое закрытие потоков, по факту обнаружения "смерти" родительского потока. Дочерних потоков.. ну прилично может быть.
При закрытии, дочерние потоки делают UDPATE одного и того же поля таблицы. Для этого использую конструкцию
transaction_start...
execute_immediate..
commit..

Получается так, что когда разом (с очень малым временнЫм разносом) к одному и тому же полю обращается десяток UPDATE - кто-нибудь обязательно валится в dead_lock. По MySQL помню такого не было, оно каким-то образом это разруливало. Хоть 100 запросов одновременно дай.

>>и да, его лучше не допускать конструктивно
Если Можно, подробнее плиз! Вопрос в том, можно ли в принципе разрулить 100 "одновременных" update без возникновения ошибочного состояния?

>>дэдлок, это не завал, это вполне себе рабочий момент,
Т.е, если возник такой момент, ТО повторить запрос?

Ранее на другом проекте, я как-то приучился вычищать код до полного отсутствия таких ошибок.

>>Сама схема с убиемем и апдейтами предполагает наличие граблей, а то и вил. Уж молчу про тонны версий-мусора.
Это случай скорее исключительный чем рабочий. Но он помог обнаружить проблему.

Ну, т.е что интересует: как так сделать чтобы запрос ждал освобождения метаданных прежде чем ломануться в update/commit, а именно так в MySQL и происходит.
В данном случае требуется делать только 1 запрос на транзакцию, а не 2 и более.

>>вангую. Пытаешься данные сессии php в базу данных запихнуть?
Не...

>>Обновление конкурирующими транзакциями одной и той же записи архитектурный косяк вашего приложения. Не надо так делать.

Ну а вот к примеру, из счетчика считываются ЛОГи телеметрии, при этом списываются бабки с лицевого счета. Допустим в некоторый момент неопределенный вследствие неопределенного состояния сети передачи данных (городской вайфай), оно читает, и допустим некий идент произвел 20 операций списания. Это грубо говоря 20 UPDATE на один аккаунт. (UPDATE... set balance=(balance-tar))

И в это же самое время, чувак делает моментальный платеж через банкинг, и ужа совсем другой интерфейс в угодное ему время делает update этого же идента. (set balance=(balance+payment_sum))). Как тут избежать одновременного UPDATE от 2х никак не связанных источника?

На практике, пару-четверку раз в год система фиксирует именно такие совпадения.

Ну или иначе, ЛОГи считываются в несколько потоков, параллельным чтением.

>>Где тут конфликты обновления ?
В этом примере как раз все "чисто", там Mysql, а он "хавает" это.

А в принципе - при чтении в 2 потока из одного устройства если в ЛОГах многократно повторяющиеся события от одного и того же идента, имеется вероятность что его обработка совпадет до милисекунды в этих потоках. (но конечно это будут разные события, но идент общий).

Суть то вопроса в том, что я случайно обнаружил, что если сделать на один идент одновременно 10 UPDATE часть из них вылетет в deadlock, вот и хочу понять с чем это едят.