Опять же на тему "готовых" решений

[metaclass]

В последних постах yakov_sirotkin про очередь асинхронной обработки задач упоминается, почему они отказались от "готового" решения в виде Oracle AQ: это дело есть только в определенных Edition оракла и при тестировании у них возникли какие-то баги в очередях.

А у меня в двух проектах есть такие задачи, с обработкой очередей. И вот я сразу себе представляю - приезжаем ставить софт, клиент сказал, что у него "есть Оракл", а по приезде оказывается что это Express Edition, а DBA, которые в случае глюков будут разбираться в них, вообще нет. "Сушите весла."

То же самое касается практически всех "готовых" решений для сложных задач, входящих в состав СУБД, ОС или там еще чего-нибудь инфраструктурного. Как только принято решение использовать что-то более сложное, чем базовые функции - с этой системы ты уже никуда не уйдешь и нужно изучать ее "вглубь" и надеятся, что в следующих релизах этот функционал не выкинут, не изменят условия лицензирования, и что он будет работать как надо в других окружениях, и что будет достаточное количество людей, его использующих, чтобы было с кем посоветоваться.

Comments

[alexclear.livejournal.com]

Какой еще кеш при первой загрузке?

Не нервничайте так, я просто спросил, а Вы уже начали бой с тенью.

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

Я, хоть слегонца, год участвовал в разработке системы управления предприятием с использованием Hibernate.
Сейчас эта система уже больше года, как в продакшн вышла.

Это будет кеш, в который надо впихнуть почти все обьекты. Смешно пошутили.

Я не пошутил, я просто спросил, мне стало интересно, разработчики документацию на Hibernate читали, или били вместо этого хуем о стол?
Вы, как я понял, тоже документацию не читали?

Прямые сиквел-запросы из ОРП?

Совершенно верно.
Более того, у нас разработкой и профилированием запросов занимался специальный человек.

Ваш коллега выше только что утверждал "трёхзвенная архитектура с чёткими границами и протоколами" - и все в шоколаде (http://metaclass.livejournal.com/366207.html?thread=2699391#t2699391).

Я не понимаю, чем даже десятизвенная архитектура помешает мне сделать native query, извините.

Привет четким границам :)

Между чем и чем?

А вы в курсе, что одного запроса скорее всего не хватит? :)

А что мне помешает сделать столько запросов, сколько я захочу?
Где здесь влияние ORM?

Простейший пример: списываем товар со склада. Считаем сальдо, смотрим, не отрицательное ли. Списываем. Все в "толстой транзакции" с высоким уровнем изолояции, иначе между вашей проверкой и списанием может проскочить списание манагера, сидяшего в соседней комнате.

Звучит пугающе, особенно про "толстую транзакцию". Но выглядит совсем не пугающе.
Ну толстая. Ну транзакция. И что?
Я обоссаться должен от страха?

[alexclear.livejournal.com]

То, что "разработкой и профилированием запросов занимался специальный человек" - это есть правильно, вопрос снят.

Как говорит один мой коллега, "ну, мы же профессионалы".

По поводу кеша ситуация примерно такая. Пользователи постоянно работают с неким подмножеством документов (поскольку они завязаны в длинные цепочки плюс история изменений). Так вот если кешировать их с попаданием на уровне ОРП в районе 95%, то сервер понадобится с обьемами памяти, в разы превышаюшей память СУБД-сервера. По сути - еще одна мини-СУБД целиком в РАМ с обьектным интерфейсом.

Понимаю.
Мы, кстати, этот кэш включили и отключили через день.
Толку никакого, одно огорчение.
У нас, правда, кэшей хватало и без этого.

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

Это Hibernate делает автоматом, этот кэш полностью прозрачен.
Но вот только он не нужен для таких систем.
Тем не менее, полезно бывает знать, что он есть.

По поводу нескольких запросов вместо одного - все прозрачно. Если вам одного не хватает, значит последуюшие будут использовать данные предыдуших.

А, речь идет именно о выборке.

Классика жанра: выбрать коллекцию и потом в цикле вызывать методы ее обьектов. В случае затыка (типа выбрали 1000 обьектов и дергаем по 5 вызовов на каждый) никаким "тьюнингом" сиквела здесь проблему не решить - требуется этот кусок полностью переписывать в виде хранимой процедуры.

Но зачем может понадобиться такая стремная задача?
Это обработка по расписанию?
Если да, то и фиг бы с ней, пусть тягает кусками по 1000 объектов и делает эти свои вызовы.
Если же это что-то, что мы хотим пользователю показать, то куда ему 1000 сущностей-то? На экран они не влезут.

Логика размазывается между СУБД и СП. Четкие границы исчезают, как химера соответствующих архитекторов.

Ну, это тоже не страшно.
Со слезами занесем логику в базу, если так уж надо.
Но еще ни иазу не видел ситуаций, когда действительно было надо.

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

Блокирует работу?
Каким образом?
Разве optimistic locking что-то блокирует?
Мне сложно представить себе ситуацию, когда EJB встал в блок на чужой транзакции, это чушь какая-то.

[alexclear.livejournal.com]

В этом типовом примере проблемы начинаются в самой постановке задачи.
Другие пользователи не должны начинать курить, пусть себе работают.
А если этот пользователь залочил документ, и его молнией убило?
Почему нельзя использовать optimistic locking, я не понимаю?

[alexclear.livejournal.com]

Нет, там никто никого не "залочил". Запустился процесс изменения состояния документа (пользователи инициировал или сервис, не важно), в процессе изменения требуется поддержать логическию целостность: пока процесс не завершился другие не могут делать что-то пересекающееся.

Это и есть "залочил".
Не скейлится.

В данном примере - нужно блокировать другие процессы, если они захотят расходовать тот же товар, что имеется в номенклатуре документа.

А зачем?

Еще грубее: два манагера не могут продать по 5 банок краски, если на складе их всего 5 даже если их процессы запустятся одновременно.

И не продадут.
Кто первый успеет изменить состояние, тот и папа, а второй не успеет.
ЛОЧИТЬ НИЧЕГО НЕ НАДО.
Надо просто использовать Hibernate и дуракцих проблем с дурацкими блокировками не будет.
Ну, или не Hibernate, а, я не знаю, здравый смысл.

[metaclass.livejournal.com]

В любом случае операция "проверить остаток и выполнить его списание" должна быть атомарной, т.е. блокировка этой сущности по которой остаток на время операции будет. Почему это нельзя сделать тремя запросами (а не 1000) - блокировка, проверка остатка, списание - не очень ясно. И почему эти запросы обязательно выполнять из SP в СУБД, а не из сервера приложений - тоже не очень понятно.

[alexclear.livejournal.com]

Ну да, будет compare-and-swap в случае optimistic locking.
Где-то должна быть атомарность, конечно.

[alexclear.livejournal.com]

Да я готов поверить, но не на слово.
Укажите, пожалуйста, сценарий, при котором предложенная стратегия не работает.

[alexclear.livejournal.com]

Я дичайшим образом извиняюсь, а где я говорил про read committed?
Уровень изоляции транзакций на СУБД меня не волнует вообще, какой-то есть, да и ладно (собственно, "какой-то" это и есть read committed, не ниже).
Вы знакомы с механизмом работы optimistic locking?
Процесс номер один выхватит эксепшн "optimistic locking failed", или как его там при попыте списать 4 бочки краски, после чего transaction monitor в самом Hibernate откатит транзакцию.
И это, замечу еще раз, безо всяких там блокировок на уровне БД.
Что интересно, это будет работать на MySQL/MyISAM, в котором вообще нельзя транзакцию открыть на уровне СУБД.

[metaclass.livejournal.com]

Ээээ. Для начала можно заблокировать остаток, а потом проверять. Т.е. второй процесс до проверки просто не дойдет, а когда дойдет - уже 5 бочек не будет.
А alexclear, судя по всему, вообще предлагает проверять постфактум(т.е. текущий остаток хранится явно и с проверкой Quantity>=0) - списывают оба, один получает отрицательный остаток и валится с ошибкой, которую мы обрабатываем на клиенте и выводим сообщение.

[alexshubert.livejournal.com]

Read commited здесь недостаточен.
да ну. no rec version + timeout

[alexshubert.livejournal.com]

блокировка этой сущности по которой остаток на время операции будет.
Не будет. Допустим,я не планирую вообще что-либо блокировать. Я пускаю снэпшот, читаю и правлю. На дедлоке вызванном конкурирующим изменением, просто перечитываю. При огромной необходимости, могу запулить запрет версий и добиться именно сводобного доступа. или запустить транзакцию с таймаутом в минуту. Не успел - роллбэк и освобождение.

[metaclass.livejournal.com]

Даже если первой операцией с остатками идет их блокировка?

[alexclear.livejournal.com]

Я вообще не понимаю, зачем блокировать остатки, тоже мне, атомная станция.
Ну, обломается запись нового значения, так как кто-то раньше успел, ну, поймает клиент исключение.
"Ну не шмогла, не шмогла".
Вполне ведь штатная ситуация.

[metaclass.livejournal.com]

Если мы сделаем в начале холостой апдейт нужной записи с остатком - то другая read committed транзакция либо свалится на этой же операции, либо будет ожидать завершения предыдущей. Вполне себе блокировка.

[alexclear.livejournal.com]

Это самое - не будет никакой блокировки, что я говорю-то.
ЗАЧЕМ?
Там делается, как я представляю, тупо UPDATE .... SET ...., version=version+1 WHERE id=myid AND version=myversion
И если изменено будет ноль строк - приплыли, кто-то бампнул версию раньше, надо кидать эксепшн и откатывать транзакцию.
Кстати, что бывает на мускуле, когда в базу пишется несколько объектов в одном методе и обламывается не первая запись, я не помню, там же придется, по сути, откатить транзакцию, которой как бы нет.
Но мы это тоже как-то моделировали.

[metaclass.livejournal.com]

Да, теперь понятно.

mysql в этом контексте пугает - если без транзакций откатывать изменения, то хибернету придется где-то у себя лог транзакции имитировать и откатывать его. Да еще как-то отличать базы - у которых можно откатить родную транзакцию, и у которых нужно ее откатывать вручную.

[alexshubert.livejournal.com]

пока процесс не завершился другие не могут делать что-то пересекающееся
меж тем на дворе шел 2009 год, версионность и рота красногвардейцев.

[alexshubert.livejournal.com]

Я бы не взял на работу автора.