JP Morgan Chase Oracle database outage

[zVlad]

А что собственно предполагается в Оракл ждать в этой конструкции? Уж не освобождения ли залоченного ресурса? А что произойдет в случае nowait?

подождать 60 секунд пока строка разлочится, на 61 секунде выдаст ORA-xxxx resource busy
при nowait выдаст сразу ORA-xxxx resource busy

ЗЫ. sckip locked в оракле тоже есть, но не докумкентирован, а значит не рекомендован к использованию. инсайдеры говорят Advanced Quenes используют такую конструкцию.

Так значит проблема с локами в Оракл тоже есть? Ах какая досада, а я то так понимал Вас и других здешних знатоков что в Оракл таких проблем нет.

[iDesperado]

Против арифметики не было никаких возражений. Что дальше то? Сколько локов на самом деле требуется и от чего это зависит - вот о чем можно было бы поговорить, а мы застряли на том что память для МФ стоит сумашедшие деньги.

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

[zVlad]

Против арифметики не было никаких возражений. Что дальше то? Сколько локов на самом деле требуется и от чего это зависит - вот о чем можно было бы поговорить, а мы застряли на том что память для МФ стоит сумашедшие деньги.

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

Не понял. О чем Вы?

[Dmitry67]

так мы договорились что дб2 не предоставляет магических средств, которые бы исключали необходимость логических локов для веб аппликаций?

[zVlad]

так мы договорились что дб2 не предоставляет магических средств, которые бы исключали необходимость логических локов для веб аппликаций?

Ба, еще один в эзотерику подался. Так и не с кем будет поговорить о делах наших скорбных.

[crypto5]

так мы договорились что дб2 не предоставляет магических средств, которые бы исключали необходимость логических локов для веб аппликаций?

Ба, еще один в эзотерику подался. Так и не с кем будет поговорить о делах наших скорбных.

Их здесь сотни, нет тысячи

[zVlad]

так мы договорились что дб2 не предоставляет магических средств, которые бы исключали необходимость логических локов для веб аппликаций?

Ба, еще один в эзотерику подался. Так и не с кем будет поговорить о делах наших скорбных.

Их здесь сотни, нет тысячи

Пока вижу только троих.

[crypto5]

так мы договорились что дб2 не предоставляет магических средств, которые бы исключали необходимость логических локов для веб аппликаций?

Ба, еще один в эзотерику подался. Так и не с кем будет поговорить о делах наших скорбных.

Их здесь сотни, нет тысячи

Пока вижу только троих.

Жена звонит мужу на мобильный:
- Алло, ты где?
- Я в машине, на садовом.
- Ты там осторожнее, по телевизору показывают - там какой-то сумасшедший по встречной полосе едет!!!
- Ты не поверишь, их здесь сотни, нет тысячи!!!

[Zombie416]

Так значит проблема с локами в Оракл тоже есть? Ах какая досада, а я то так понимал Вас и других здешних знатоков что в Оракл таких проблем нет.

А в чем состоит проблема-то? Ну да, можно таймаут указать в команде, хоть в Oracle, хоть в MS SQL, хоть в MySQL. Толку-то.

Вы позабыли, возможно, но цирк начался с того как одним знатоком DB2 было написано следующее:

логоческие локи - это проявление слабости (незнаю какой) native локов тех БД с которыми видимо Вы работаете. В случае ДБ2 на МФ в этом нет необходимости и этим реально не пользуются. Хотя я не стану исключать что спец, вроде Вас, попав в ДБ2 станет пытаться применять свой неверный подход к этому вопросу.

Было приведено несколько примеров, на которых многократно, с "пожалуйста", предлагалось продемонстрировать "верный подход к этому вопросу". Как оказалось, верный подход заключается в том чтобы ничего не делать, проблему не решать, а вопрощающим рассказывать о их тупости и невежестве. Подход знакомый, соблюден со всеми приличиями (включая упоминания всяких сертификатов и грозных аббревиатур), но верным его назвать трудно

[zVlad]

....

Вы позабыли, возможно, но цирк начался с того как одним знатоком DB2 было написано следующее:

логоческие локи - это проявление слабости (незнаю какой) native локов тех БД с которыми видимо Вы работаете. В случае ДБ2 на МФ в этом нет необходимости и этим реально не пользуются. Хотя я не стану исключать что спец, вроде Вас, попав в ДБ2 станет пытаться применять свой неверный подход к этому вопросу.

Было приведено несколько примеров, на которых многократно, с "пожалуйста", предлагалось продемонстрировать "верный подход к этому вопросу". Как оказалось, верный подход заключается в том чтобы ничего не делать, проблему не решать, а вопрощающим рассказывать о их тупости и невежестве. Подход знакомый, соблюден со всеми приличиями (включая упоминания всяких сертификатов и грозных аббревиатур), но верным его назвать трудно

Хорошо. Давайте попробуем спуститься на уровень Ваших примеров. Не судите строго если мой пример Вам тоже покажется наивным.

1. Делаем раз (выбираем "свободные" тикеты на запрошенный рейс):

Code: Select all

SELECT * FROM Tickets WHERE <condition> SKIP LOCKED DATA

2. Даем клиенту выбрать интересующий его тикет, и выдаем в ответ на его выбор:

Code: Select all

SELECT * FROM Tickets WHERE TicketID=@TicketID .... FOR UPDATE

RDBMS накладывает 1 (один) лок на одну строку.

3. Coобщаем клиенту что у него 15 минут чтобы купить понравившийся ему билет и запускаем счетчик (по времени). Клиент принимает решение. Мы завершаем UPDATE и заканчиваем транзакцию. Локи в количестве 1 (одна) штука удаляется.

Если посмотреть не так предвязато как это любят мои "единомышленники" здесь на форуме, то получается ровным счетом тоже самое что и в Вашем примере, только проще и с большим автоматизмом, т.к. никаких исключительных ситуаций обрабатывать (пусть даже "элементарно") не нужно, все сделает RDBMS.

[iDesperado]

2zVlad

1.если у вас уровень Read Commited в шаге 2 вы получите эксепшен, т.к. пока клиент раздумывал запись которую выбрал клиент могли заблокировать конкурирующие транзакции
если у вас уровень выше, вы в шаге 1 заблокировали на 15 минут все свободные билеты.

2. как вы вебного пользователя собрались связывать с транзакцией субд ?

[crypto5]

....

Вы позабыли, возможно, но цирк начался с того как одним знатоком DB2 было написано следующее:

логоческие локи - это проявление слабости (незнаю какой) native локов тех БД с которыми видимо Вы работаете. В случае ДБ2 на МФ в этом нет необходимости и этим реально не пользуются. Хотя я не стану исключать что спец, вроде Вас, попав в ДБ2 станет пытаться применять свой неверный подход к этому вопросу.

Было приведено несколько примеров, на которых многократно, с "пожалуйста", предлагалось продемонстрировать "верный подход к этому вопросу". Как оказалось, верный подход заключается в том чтобы ничего не делать, проблему не решать, а вопрощающим рассказывать о их тупости и невежестве. Подход знакомый, соблюден со всеми приличиями (включая упоминания всяких сертификатов и грозных аббревиатур), но верным его назвать трудно

Хорошо. Давайте попробуем спуститься на уровень Ваших примеров. Не судите строго если мой пример Вам тоже покажется наивным.

1. Делаем раз (выбираем "свободные" тикеты на запрошенный рейс):

Code: Select all

SELECT * FROM Tickets WHERE <condition> SKIP LOCKED DATA

2. Даем клиенту выбрать интересующий его тикет, и выдаем в ответ на его выбор:

Code: Select all

SELECT * FROM Tickets WHERE TicketID=@TicketID .... FOR UPDATE

RDBMS накладывает 1 (один) лок на одну строку.

3. Coобщаем клиенту что у него 15 минут чтобы купить понравившийся ему билет и запускаем счетчик (по времени). Клиент принимает решение. Мы завершаем UPDATE и заканчиваем транзакцию. Локи в количестве 1 (одна) штука удаляется.

Если посмотреть не так предвязато как это любят мои "единомышленники" здесь на форуме, то получается ровным счетом тоже самое что и в Вашем примере, только проще и с большим автоматизмом, т.к. никаких исключительных ситуаций обрабатывать (пусть даже "элементарно") не нужно, все сделает RDBMS.

Есть мнение что когда зайдет следующий клиент и сделает запрос:

Code: Select all

SELECT * FROM Tickets WHERE <condition> SKIP LOCKED DATA

то он увидит залоченный билет, потому что операция select чтения является compatible с локом записи, который вы поставили используя select ... for update.

ну и присоединяюсь к вопросам iDesperado

[sp123]

Моя цель лишь поправлять наиболее горячие головы здесь на форуме, развеивая мифы о МФ и ДБ2 в частности. Увы в этой область очень высок уровень мифотворчество.

Тут немного не согласен. Никто обычно не сочиняет мифов о неуловимом Джо, а для большинства присутствующих DB2 и MF - это как раз тот самый Джо и есть. Кто постарше, тот свой выбор сделал уже давно, и ему данная платформа глубоко параллельна. Ну работает оно где-то там, ну и бог с ним. Для нового поколения - тем более, им важнее попасть в свежую струю, чтобы было кул, и DB2 в это ну никак не вписывается. В-общем, наличие каких-то мифов о DB2 - это и есть самый главный миф .

P.S. На этой неделе интервьюировал одного перца. У перца последний проект был на связке MF - Oracle. Ребята выгружали из MF данные в виде плоских файлов, грузили их в Oracle, там ваяли какой-то back-end и front-end, данные усиленно массировали и отправляли назад. Я ему говорю - все это интересно, но ведь можно было бы все то же самое сделать на самом MF, там у вас и DB2 есть, и REXX, и вообще много всего, на хрена такой overhead? А он грит - так все проще и быстрее...

[zVlad]

2zVlad

1.если у вас уровень Read Commited в шаге 2 вы получите эксепшен, т.к. пока клиент раздумывал запись которую выбрал клиент могли заблокировать конкурирующие транзакции
если у вас уровень выше, вы в шаге 1 заблокировали на 15 минут все свободные билеты.

2. как вы вебного пользователя собрались связывать с транзакцией субд ?

1. Совершенно верно. Точно так же как и в примере Zombie416.

2. Не знаю. Никогда этим не занимался. Как то делается.

[iDesperado]

Есть мнение что когда зайдет следующий клиент и сделает запрос:

Code: Select all

SELECT * FROM Tickets WHERE <condition> SKIP LOCKED DATA

то он увидит залоченный билет, потому что операция select чтения является compatible с локом записи, который вы поставили используя select ... for update.

думаю не увидит, WHERE <condition> SKIP LOCKED DATA будет пытаться ставить шаред лок (или лок намерений, но тут не суть важно), который не совместим с апдейт локом. поэтому SKIP LOCKED DATA пропустит все, что залочено запросом FOR UPDATE