|
|
Страници по тази тема: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | (покажи всички)
|
Тема
|
 Re: ами ...
[re: wiz]
|
|
| Автор |
salle (един такъв) |
| Публикувано | 18.12.08 13:35 |
|
|
Страшна логика извади
Понеже колите в масовия случай не катстрофират затова дай да ги оптимизираме като махнем всичките му там колани, въздушни възглавници, брони и тем подобни.
Явно си пропуснал урока, че и в най-простия софтуер трябва да се отчитат въцможно на-лошите сценарии.
Някой ден ще се смееш на собствените ти глупости
Колкото до масовия случай всеки ден се сблъсквам с такива масови случаи където това за милисекундите е в рамките на мечтите.
| |
|
Тема
|
Re: ами ...
[re: wqw]
|
|
| Автор |
salle (един такъв) |
| Публикувано | 18.12.08 13:44 |
|
|
>> SELECT * FROM MyTable WHERE IsReserved = 0 LIMIT 1 FOR UPDATE;
ще осъмне с X row lock върху един ред (първия намерен) в 100% от случаите. <<
" Ето това е най-подвеждащото изказване. Значи ако има редове с IsReserved != 0 те няма да се заключат така ли? При положение че самия SELECT ги "пипа"? Говорим за InnoDB. "
Ами пробвай като не вярваш
SELECT * FROM MyTable WHERE IsReserved = 0 FOR UPDATE;
защльючва само редовете за които IsReserved = 0 и не заключва нито един от другите редове.
А идеята ти, че самият SELECT "пипа" редовете за които IsReserved != 0 ще я отдам на недоспиване, липса на кофеин, липса на бира (или твърде много бира ако такова нещо е възможно). Помисли пак на свежа глава.
"Относно REPEATABLE READ, с подобна WHERE клауза няма друг начин да ги предотврати освен tab lock, за разлика от READ COMMITED където би трябвало да сложи множество row lock-ове.. "
Ами явно има
Хайде вземи та пробвай InnoDB или поне прочети да видиш как работи. Ти говориш за някакви теоретични разбирания по въпроса докато аз ти описвам конкретна реализация която работи по този начин от години насам.
| |
|
Тема
|
Re: нещо ме бъркаш за MyISAM
[re: wiz]
|
|
| Автор |
salle (един такъв) |
| Публикувано | 18.12.08 13:48 |
|
|
"въобще за MyISAM не съм писал, нещо се бъркаш "
Мдам .. така е .. съжалявам.
Нещо ви бъркам с тези подобни прякори wqw и wiz ... а и като стил на писане донякъде
| |
|
Тема
|
Re: ами ...
[re: salle]
|
|
| Автор |
wiz (100 тонa змей) |
| Публикувано | 18.12.08 13:51 |
|
|
обърка ме с wqw, сега пък ме разсмиваш с друго
ако почнеш да се защитаваш от всичко възможно що не направиш бункер с 5 метра бетонова стена и да живееш в него да те пази от метеорити или падащи самолети?
казано по друг начин е добре да се дозира защитата а не да се предпазваш от илюзии, ясно е че колите имат защити при катастрофа ама и те са с ограничени възможности а не са дебела по няколко метра стена
твоите опитите да се защитаваш от случай които е малко вероятно да се случат са нещо подобно
No pain, no gain Редактирано от wiz на 18.12.08 13:53.
| |
|
Тема
|
Re: ами ...
[re: salle]
|
|
| Автор |
wiz (100 тонa змей) |
| Публикувано | 18.12.08 13:55 |
|
|
ха Явно си пропуснал урока, че и в най-простия софтуер трябва да се отчитат въцможно на-лошите сценарии.
по скоро на теб и на wqw някои повърхностен преподавател със смешна заплата ви е напълнил главите с евтини теории които опитвате да ми ги пробутате ама пред мен не минават
No pain, no gain
| |
|
Тема
|
 с други думи
[re: salle]
|
|
| Автор |
wiz (100 тонa змей) |
| Публикувано | 18.12.08 14:10 |
|
|
ако заявките почнат да се изпълняват за по дълго от 0,05 секунда например значи компа е претоварен и може да се връщат потребители а не да се правят опити да им се прави резервация
лесно може да се сложи код да мери за колко се прави заявка и ако е над опредлено време да прати съобщение че в момента е претоварена системата
например може да се мери за колко се изпълнява селект заявката която показва слисъка с редове от които се избира или update която записва резервацията, ако е прекалено голямо това число показва съощение че има претоварване
а ти някои ден може да съжаляваш че не живееш бункер ама сигурно много повече ще съжаляваш ако всеки ден си в бункер
ето предложение за теб
No pain, no gainРедактирано от wiz на 18.12.08 14:52.
| |
|
Тема
|
Re: ами ...
[re: wiz]
|
|
| Автор |
wqw (АзСъмЖив) |
| Публикувано | 18.12.08 15:08 |
|
|
Боже, колко си наивен! По-скоро това е което ние преподаваме на заблудени овце като тебе -- реални use-case-ове от практиката, подковани със стабилна теория преди това.
| |
|
Тема
|
Re: "собствен екзекютив "?
[re: wiz]
|
|
| Автор |
bira_more (бира) |
| Публикувано | 18.12.08 15:46 |
|
|
А ми не е така. Ако е мой екзекютив - няма да има допълнителни таблици, нито повторни проверки, нито изчакване, нито потенциални серийни колизии.
Bеer? Mоre?
| |
|
|
|
Е то ако е да се гръмнеш в крака - начини много.
Ама ние и сега имаме рядко колизии, и смятам че ще се справим.
Bеer? Mоre?
| |
|
Тема
|
пак ме бъркаш със себе си
[re: wqw]
|
|
| Автор |
wiz (100 тонa змей) |
| Публикувано | 18.12.08 16:06 |
|
|
очевидно за теб "реални use-case-ове от практиката, подковани със стабилна теория" се нарича повърхностното ти разбиране за "critical section-и и random изчаквания" и други подобни
благодаря че ме разсмиваш ама гледай поне да четеш и да разбираш изчерпателно и подробно за какво става дума преди да пишеш/говориш
No pain, no gainРедактирано от wiz на 18.12.08 17:23.
| |
|
Страници по тази тема: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | (покажи всички)
| 
|
|
