База данни - MySQL 5.0.21
В една таблица постоянно се добавят записи.
Тези записи се обработват от хора - има php интерфейс.
Целта е агента да избере необработен ред, да го обработи и да върне отговора.
Проблемът - има случаи когато 2ма агенти взимат един и същи ред. Рядко ама става. И понеже скрипта записва кой кога какво взима (в друга таблица) се вижда че пичовете успяват да вземат същия ред с точност до секунда.
Правихме врътки - тоест скрипта дръпва реда за обработка и го маркира на следваща команда. Опитахме и update...
Сега планираме преход към InnoDB (от MyISAM).
Това е едния подход - да успеем да направим нещата с транзакции. Чуденката ми е - дали select може да блокира само един ред, така че следващ select да избере следващия ред (а не да чака първата транзакция да приключи).
Другия подход - ще си спретна едно допълнително скриптче което ще си слуша на някой порт, и ще връща наистина последователно каквото му искат. Сигурно ама не е елегантно.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

оплетено ми се вижда твоето описание

какво мислиш за идеята да смениш реда на записване и вземане?

в смисъл първо записва че ред е взет и след това го взема
следващия първо гледа дали реда не е взет и ако е свободен резервира и взема

може да се сложи и код да избегне едновременна резервация на ред

този начин не зависи от базата и е за такива които предпочитат да пишат код

също може да прочетеш

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от wiz на 14.12.08 01:30.

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

hell storms, rush over the earth
bestial invasioooooooooooon

Тъпото е че баш това парче го прави един друг колега. Мисля че е опитал подобен подход.
В смисъл - единия процес проверява, другия променя (щото вече е проверил), първия също променя - понеже не е било променено когато е проверявал - кофти.

Не смее да легне на changed rows (след update) щото ползвал persistent connection - и не е много ясно - на него, а на мен ич - какво ще стане.
Май ще си заложа на отделния скрипт - поне такива съм правил доста.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

ми като чета как пишеш оставам с впечатление че ти и твоя колега сте затрупани със задачи, нямате време да огледате картинката като цяло и е добре вашите шефове да почерпят някои да помогне

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от wiz на 14.12.08 21:28.

И това сме го мислили. Ама и то не ми харесва като решение.
Бачкаме по наследен код. Шефовете са на поне 10 000 км. И има времена - никакъв зор. Тогава тръгваме да оптимизираме - и изниква някакъв пожар. Ама пожар - за вчера. И след това - като нацвъкаме колкото можем какъв да е код, само и само нещо да стане - пак покой и пак чистене и оптимизации.
Картинката като цяло представлява купчини таблици - голяма част от които не се ползват, ама не смеем да трием щото знае ли човек. Към това добавяш още купчини php за веб, perl за AGI, промени в Астериск.
А бе веселба.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

ми това е начин на работа на много места, рано или късно се стига до там че нищо съществено не може да се добави понеже е голяма плетеница

както казваш има начини да се подредят нещата по добре ама не е лесно и струва пари

иначе не ми се вярва че ще намериш кои знае колко по добро решение от функцията която предлагам

Съдържаниет е скрито
Влезте за да го видите

колко са юзърите, които ще заявяват ред за промяна по него? 5, 20, 100, няколкостотин?

hell storms, rush over the earth
bestial invasioooooooooooon

казано с други думи начина да ти хареса повече е вашите шефове да почерпят(някои като мен) и заедно с вас и тях да се подредят нещата с мисъл за напред

ама цената на такова решение е доста по голяма от текущите разходи които правят сега вашите шефове и сигурно не им се дава толкова, подобно тъпо отношение на парче като че ли е епидемия от глупост по фирмите

а и има много възможности проекта да се провали заради някоя добре звучаща почти безсмислена екстра и да завърши с несериозно оправдание като твоето

И това сме го мислили. Ама и то не ми харесва като решение.

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

2 - 5 най-много от общо може би 20.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите