Е - ключа от бараката е в
select .... for update
Поне така разбрах. Иначе - и ние установихме че select'ите има голяма вероятност да видят едно и също - и да стане същото мазало, каквото е в момента или дори по голямо.

Bеer? Mоre?

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

Чувствам се задължен да измуча, макар и да си "нахранил" wiz.

Auto-commit-а на MyISAM е дълбока моя заблуда. Сега вече "прогледнах" и опасенията ми се сбъднаха на 100% -- по-добре да работя с .txt файлове отколкото с подобна "RDBMS".

bira_more може и да чете, но надали разбира какво точно се случва при твоето предложение. Прекъсни ме ако греша в следващите обяснения, в които ще се опитам да развенчая заблудата, в която ти лично го въведе, че едва ли не със SELECT ... FOR UPDATE ще постигне single row lock върху първия ред подходящ за резервация.

0. Приемам, че InnoDB е относителна стандартна имплементация на RDBMS без да съм запознат с конкретната имплементация.
1. Нека заявката изглежда така SELECT * FROM MyTable WHERE IsReserved = 0 FOR UPDATE
2. Нека в MyTable имаме няколко реда с IsReserved = 1
3. В зависимост от коректността на статистиките на db engine-а + ефективността на алгоритмите за lock escalation, съм готов да се обзаложа че в 95%+ от случаите заявката ще "осъмне" с tab lock.
4. Ако има индекс по IsReserved (нещо безумно като изпълнение, но "решение" което с голяма вероятност wiz би придложил гледайки предиката в WHERE клаузата на заявката) 100% от случаите ще имаме index lock на целия индекс.
5. В зависимост от нивото на изолация на транзакциите db engine-а може да се опита да предотврати "фантоми" и веднага ще сложи tab lock
6. "На око" вероятността само за row lock-ове при подобна заявка е минимална.

Сега виждам това предложение:
UPDATE x SET ......,
processed = (@las_processed := UUID()) ...
WHERE processed IS NULL LIMIT 1;

Питам се, след като на MyISAM му липсва A-то в ACID-а, може ли две сесии да UPDATE-нат един и същ ред едновременно и в резултат това:

SELECT ... WHERE processed = @last_processed;

... да не върне нищо? Склонен съм да предположа, че бирата и Co. ще го докажат в практиката или по-рано ако стрес-тестват. Без транзакции е тегаво, а веселбата с MyISAM е пълна. Бих се хванал за custom lock-овете като удавник за сламка в случая. Добре че понe има work around за емулация на critical section-и.

cheers,
</wqw>

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

"едва ли не със SELECT ... FOR UPDATE ще постигне single row lock върху първия ред подходящ за резервация. "

При ENGINE=InnoDB

SELECT ... WHERE ... LIMIT 1 FOR UPDATE;

ще постави row lock върху първия намерен ред отговарящ на WHERE клаузата.

"1. Нека заявката изглежда така SELECT * FROM MyTable WHERE IsReserved = 0 FOR UPDATE
2. Нека в MyTable имаме няколко реда с IsReserved = 1
3. В зависимост от коректността на статистиките на db engine-а + ефективността на алгоритмите за lock escalation, съм готов да се обзаложа че в 95%+ от случаите заявката ще "осъмне" с tab lock. "



SELECT * FROM MyTable WHERE IsReserved = 0 FOR UPDATE;

ще осъмне с eXclusive row lock върху всички редове с
IsReserved = 0 в 100% от случаите дори и когато това са всички редове в таблицата.

SELECT * FROM MyTable WHERE IsReserved = 0 LIMIT 1 FOR UPDATE;

ще осъмне с X row lock върху един ред (първия намерен) в 100% от случаите.

Шансът при SELECT ... FOR UPDATE InnoDB да постави Tabel lock е нулев. Мога и да обясня защо ако трябва.

"4. Ако има индекс по IsReserved (нещо безумно като изпълнение, но "решение" което с голяма вероятност wiz би придложил гледайки предиката в WHERE клаузата на заявката) 100% от случаите ще имаме index lock на целия индекс."

Не знам какво точно имаш предвид под index lock в случая. InnoDB използва clustered index където държи Primary Key и точно това е което заключва. Няма вариант да заключи целия индекс обаче освен разбира се когато трябва да заключи всички елементи.

"5. В зависимост от нивото на изолация на транзакциите db engine-а може да се опита да предотврати "фантоми" и веднага ще сложи tab lock "

InnoDB предотвратява фантомите в почти всички случаи дори на ниво REPEATABLE READ, но това всъщност няма значение в случая.

"Питам се, след като на MyISAM му липсва A-то в ACID-а, може ли две сесии да UPDATE-нат един и същ ред едновременно и в резултат това: "

Не.

Въпросът кога точно на MyISAM му липсва A-то e с леко повишена трудност :) Не много, но да речем 6 по десетобална скала ;)

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

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

MyISAM поддържа заключване само на ниво таблица.

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

Редактирано от salle на 18.12.08 03:20.

"Само не съм сигурен какво се случва ако PHP ползва persistent connection. "

persistent connection към MySQL носят само главоболия. Не случайно в mysqli ги махнаха въобще.

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

"Е - ключа от бараката е в
select .... for update "

Не съвсем. select .... for update ти дава възможност да заключваш отделни редове, което е за предпочитане при много паралелни сесии пред заключване на цяла таблица.

Това все още не ти решава проблема, че две сесии могат да променят един и същ ред последователно. Първо едната после другата.

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

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

като гледам със salle сте тръгнали към нещо от което няма полза, не би трябвало да ползвате UUID() и LIMIT щото таблицата трябва да има primary key а с него се взема само 1 ред и е ясно че тои се обработва

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

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

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

>> SELECT * FROM MyTable WHERE IsReserved = 0 LIMIT 1 FOR UPDATE;

ще осъмне с X row lock върху един ред (първия намерен) в 100% от случаите. <<

Ето това е най-подвеждащото изказване. Значи ако има редове с IsReserved != 0 те няма да се заключат така ли? При положение че самия SELECT ги "пипа"? Говорим за InnoDB.

Относно REPEATABLE READ, с подобна WHERE клауза няма друг начин да ги предотврати освен tab lock, за разлика от READ COMMITED където би трябвало да сложи множество row lock-ове..

Index lock е нещо което ефективно предотвратява фантоми -- просто не позволява да се модифицира (insert/delete) съответния индекс.

Защо трябва да са множество row lock-ове? Неко сложим ORDER BY за да ни е детерминистичен резултата от заявката: SELECT * FROM MyTable WHERE IsReserved = 0 ORDER BY id LIMIT 1 FOR UPDATE;

Ако сесия А установи, че id=1 е резервирано и "заключи" id=2, междувременно сeсия Z освободи id=1, то сесия B ще може да намери id=1 преди сесия A да commit-не. Което може да е търсено поведение в случая, знам ли.

cheers,
</wqw>

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

въобще за MyISAM не съм писал, нещо се бъркаш

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

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

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

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

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

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

ясно е че може да се претовари някои компютър и 1-2 най прости заявки да отнемат седмици или години ама тва е изключение а не масов начин на работа

ще се съгласиш ли че в масовия случай заявките се изпълняват за милисекунди? включително и на този които ползваме в момента - clubs.dir.bg

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

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

ми до колкото разбрах от обясненията на бирата тва е сценария които се търси:

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

тоест има primary key при потребител, с този primary key се взема реда които е избран(select ... where id=pk), редактира се и се записва обратно в базата (update ... where id=pk)

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

обаче като гледам кво пише бирата почвам да се съмнявам че таблицата има primary key
което значи че базата е несериозна и трябва да се добави на таблицата primary key ...

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

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