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

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

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

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

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

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

Редактирано от wiz на 17.12.08 00:33.

"Смятам, че се предоверяваш на salle -- той работи по репликацията а не по db-enigine-а. "

Това пък какво беше?

Аз толкова години да си мисля, че знам какво работя а то какво се оказа. Не само, че не съм знаел и съм бил работел нещо съвсем друго ами и имало хора които го знаят по-добре от мен.

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

Редактирано от salle на 17.12.08 12:49.

"1. LOCK на dummy "

Излишно е да хабиш цяла таблица при положение, че има функции като

GET_LOCK(), RELEASE_LOCK(), IS_FREE_LOCK()

Освен това какво точно печелиш по този начин в сравнение с единичен UPDATE който гарантира, че ще се промени ред само ако вече не е промемян?

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

LIMIT 1 ще ти позволи да променяш само по един ред а с @променлива можеш да вземеш току що редактирания ред.


UPDATE x SET ......,
processed = (@las_processed := UUID()) ...
WHERE processed IS NULL LIMIT 1;

SELECT ... WHERE processed = @last_processed;

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

Не ме карай да се смея, твоето "решение" никога няма да полети. Някой трябва много да ми е неприятен, за да го посъветвам да изполва random изчаквания и подобни простотии.

И вземи прочети малко за

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

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

Нищо не печеля и "решението" щеше да е излишно ако MyISAM поддържаше малко по custom транзакции от auto-commit. Просто дори в случая може да се окаже, че не става със single UPDATE и тогава да се върне на мануални LOCK-ове.

Ясно е че супер повърхностно съм погледнал ресурсните LOCK-ове на MySQL и решението с таблица е хак. Най-добре е да има примитив critical section и вероятно това емулират съответните функции. Просто всеки диалект решева проблема сам за себе си, във T-SQL има sp_getapplock/sp_releaseapplock за сериализиране на достъп до ресурси (файлове, други бази) извън lock management-а на db engine-а или на distributed transaction координатора.

А това за отдела за репликация е долна инсинуация от моя страна -- просто обичам да се ебавам с авторитети -- от малък съм така :-)) Nothing personal дето се вика, но нишаните на бирата са ми леко смешни.

cheers,
</wqw>

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

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

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

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

например ако кода за резервация отнема 0,001 сек като чакаш 0,1 сек след това ще може да видиш дали е дублирана резервация и втория да се откаже без това забавяне да се усети

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

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

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

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

Значи викаш лесно мериш милисекунди? Със ANSI SQL? С голяма точност? Оптимист!

Стойността, която ще получиш е по-скоро random, но това е най-малкият ти проблем. Решението ти е мърляшко, абсолютно shake-и и никога няма да можеш да го стабилизираш. Типично случай на "write once, debug forever"!

(Още не съм те почнал тебе -- следват две изречения ad-homenium атака)
Какво ли се занимавам с тебе, поредния architecture astronaut! Ходи ръгай hibernate-а, зарежи SQL-а не е за тебе!

cheers,
</wqw>

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

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

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

като сложиш 100 пъти по голямо изчакване си готов

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

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

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

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

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

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

Виж сега, 100 тона шит, твоите "решения" не вярвам дори да са преписани от някъде, освен от някой наръчник на провалени проекти.

Моето предложение е тривиално -- емулиране на critical section със средствата на RDBMS-то -- не съм "преписвал" (какво и да значи това), а комбинирам техники по малко по-находчив начин.

За сведение, твоите random изчаквания, умножени по random коефициент в интервала 10-100 са пъти по-нескалируеми и 100%-ов bottle-neck на една multi-user система. Явно не си пипал достатъчно, за да се осъзнаеш че в такава среда минорните "забежки" се наказват през пръстите.

>> като чакаш 0,1 сек <<
Значи имаш throughput от само 10 резервации в секунда? При изисквания от пимерно 500? Добро е, спор няма...

>> и втория като види че е пуснал ... <<
А третия? Четвъртия? Тоя race condition ще е пълен цирк да се наблюдава! Сигурен съм, че ще има потребители, които ще резервират мигновено и такива, които няма да могат да се доредят, дори и при най-песимистичен timeout на заявката.

cheers,
</wqw>

Редактирано от wqw на 17.12.08 18:46.