Диалог из оракловой хранимки.

← →
ANB © (2008-01-29 17:57) [0]

Чего то не видно толковых вопросов.
А вот у меня давно назрел и толкового решения я так и не придумал.
Значится проблема : имеем хранимку, которая обрабатывает много документов/записей. В процессе обработки возникает проблема, вариант решения которой неплохо было бы уточнить у пользователя. Причем для разных документов вариант может быть разный.
Вопрос : как бы получше, с минимальными ресурсами, организовать обратную связь с клиентом, не прерывая работы хранимки ?

← →
DiamondShark © (2008-01-29 18:35) [1]

> Вопрос : как бы получше, с минимальными ресурсами, организовать
> обратную связь с клиентом, не прерывая работы хранимки ?

Ответ: получше было бы так не делать.

А можно в Оракле использовать внешние DLL или COM-объекты? Если можно, то реализовать связь через них.

← →
clickmaker © (2008-01-29 18:37) [2]

разбей хранимку на части "без вопросов"
между ними на клиенте вставляй вызов диалога

← →
Petr V. Abramov © (2008-01-29 18:51) [3]

> ANB © (29.01.08 17:57)

че-то ты недоброе задумал :)
навскидку можно через AQ, примерно так:
на клиенте подписываешься на какую-нить очередь.
в хранимке когда надо спросить, кладешь в эту очередь сообщение с сутью вопроса и виснешь на dbms_aq.listen. когда клиент удосужится ответить, он кладет в очередь, которую ты listen, сообщение с сутью ответа. Хранимка отвисает, проверяет, что сообщение именно ей, если да, продолжает работать, если нет - висеть.

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

← →
clickmaker © (2008-01-29 18:53) [4]

> Сам не пробовал и тебе не советую, чем дольше транзакция,
> тем больше вероятность

в данном случае вообще нельзя стартовать транзакцию

← →
Petr V. Abramov © (2008-01-29 18:56) [5]

> clickmaker © (29.01.08 18:53) [4]

а транзакция никого не спрашивает, сама стартует на первом запросе.

← →
clickmaker © (2008-01-29 18:58) [6]

> [5] Petr V. Abramov © (29.01.08 18:56)

а в оракуле это не настраивается?
тогда получится, что сервер может ведь и откатить слишком застоявшуюся транзакцию, так и не дождавшись юзера с перекура

← →
ANB © (2008-01-29 18:59) [7]

> Ответ: получше было бы так не делать.

Дык и не делаю, потому как не умею :)

> разбей хранимку на части "без вопросов"
> между ними на клиенте вставляй вызов диалога

Есть у нас примеры таких хранимок - видели бы вы их код . . . А править их - ваще полное счастье . . .

> в данном случае вообще нельзя стартовать транзакцию

В оракле она сама стартует при первом изменении данных.

> на клиенте подписываешься на какую-нить очередь.

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

← →
Правильный_Вася (2008-01-29 18:59) [8]

смешивать бизнес-логику и интерфейсные решения - дурной тон

← →
clickmaker © (2008-01-29 19:05) [9]

> Есть у нас примеры таких хранимок - видели бы вы их код
> . . . А править их - ваще полное счастье . . .

Ну вы уж определитесь... Тогда проектируйте бизнес-логику, чтобы она вопросов не задавала. Собирайте все данные изначально, и скопом в хранимку.
Как вариант, делать все что можно, без вопросов, остальное складывать в некую очередь. По завершении хранимки, если там что-то есть, спрашивать у клиента: "то-то и то-то осталось недоделанным, добить?", ну и какие-то доп. данные, может

← →
Petr V. Abramov © (2008-01-29 19:05) [10]

> clickmaker © (29.01.08 18:58) [6]

он терпеливый

> ANB © (29.01.08 18:59) [7]
> Проблема в том, что очередь нужно опрашивать.

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

← →
Petr V. Abramov © (2008-01-29 19:09) [11]

в любом случае шанс собрать все известные и неизвестные 600-е сильно повышается.

← →
Petr V. Abramov © (2008-01-29 19:31) [12]

основная проблема, ИМХО, будет не получить уведомление, а ответить, т.е выполнить запрос, пока не завершился первый.

← →
MsGuns © (2008-01-29 20:28) [13]

Побочный эффект почитателей все что можно и нельзя волочить на сервер

← →
Desdechado © (2008-01-29 21:19) [14]

> В процессе обработки возникает проблема, вариант решения
> которой неплохо было бы уточнить у пользователя. Причем
> для разных документов вариант может быть разный.
Сложить в настройки. Отдельно режим настроек сделать, которые потом (до запуска ХП) можно просто в сессионные переменные пакета записать и проверять при необходимости в процессе выполнения хранимки.

← →
Petr V. Abramov © (2008-01-30 01:44) [15]

это все может иметь смысл, если в конторе зоопарк систем, и в какой-то момент все сливается в ПРАВИЛЬНУЮ, т.е. oracle :)
и может возникнуть ситуация, когда, спотыкнувшись на 10020-м документе, остальные 50000 сливать либо не надо, либо под ответственность оператора заливки.

← →
ANB © (2008-01-30 11:15) [16]

> Сложить в настройки. Отдельно режим настроек сделать, которые
> потом (до запуска ХП) можно просто в сессионные переменные
> пакета записать и проверять при необходимости в процессе
> выполнения хранимки.

Обломайся. Пытались - не получается. Пока тупо оставляем документы необработанными и пишем их в лог. Юзеры жалуются - типа на старой системе мона было ответить на вопрос и идти дальше.
К сожалению, запросы выполнять, пока хранимка выполняется, нельзя.
Из-за чего проблема : есть старая система, в которой вся бизнес-логика живет на клиента.
Соответственно, регистрим, например, документ. В процессе выясняется, что на счете возникает красное сальдо. В старой системе пользователя справшиваем - чего с ним делать. Т.е. отменить регистрацию, заболтить на проблему, поставить документ на картотеку (и некоторые параметры картотеки). Причем алгоритмизировать выбор не получается (иначе бы сразу так сделали), т.е. юзер по ему известным причинам может выбрать любой вариант.
В новой системе потихоньку переписываем по надобности логику на хранимки. Новый функционал сразу пишем на хранимках. Есть совсем новячая система, для которой вообще хотелось бы закрыть доступ к таблицам и все сделать на хранимках.
Есть конечно простой выход - в хранимке обрабатывать один документ и вызывать ее циклом с клиента, но это намного медленнее.
Как доп. фича от реализации такой функции - можна с клиента вместо поднятия диалога просто трассировать ход выполнения хранимки (все равно клиент ничего не делает, в лучшем случае крутить мультики).

Тут я накопал путь к решению - есть пакетик utl_tcp. Седня попробую.

← →
ANB © (2008-01-30 11:22) [17]

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

← →
ANB © (2008-01-30 11:26) [18]

Милин 2. Чего то в оракле не хватает - не ботает пакет.
Говорит, что не хватает класса TCPConnection.
Вывод - если базу ставить по дефолту - пахать не будет.
Очень жаль.

← →
ANB © (2008-01-30 11:30) [19]

Хотя не. На 9-ке стартует, но не видит мою машину.

← →
Desdechado © (2008-01-30 11:40) [20]

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

Смешано 2 вещи - предварительные проверки и собственно сохранение. 2 хранимки было бы в самый раз.

← →
ANB © (2008-01-30 11:58) [21]

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

← →
ANB © (2008-01-30 12:42) [22]

> Смешано 2 вещи - предварительные проверки и собственно сохранение.
> 2 хранимки было бы в самый раз.

Да при грамотном проектировании такая проблема вылезти не должна.
Но ктож у нас грамотно проектирует ? Посему, по любому вылезет.

← →
clickmaker © (2008-01-30 12:44) [23]

> [22] ANB © (30.01.08 12:42)

сколько не проектировал баз - ни разу такой нужды не было.
точно что-то не так делал

← →
ANB © (2008-01-30 12:47) [24]

> clickmaker © (30.01.08 12:44) [23]

А проектировал базу, у которой тонкий клиент и ВСЯ логика живет в хранимках + метаданные ?

← →
clickmaker © (2008-01-30 12:55) [25]

> [24] ANB © (30.01.08 12:47)
>
> > clickmaker © (30.01.08 12:44) [23]
>
> А проектировал базу, у которой тонкий клиент

почти. Логика была в хранимках и сервере приложений. Но последний тоже вопросов юзеру не задавал, ибо был сервисом

← →
ANB © (2008-01-30 13:16) [26]

> сервере приложений

Ни на фиг не нужен обычно. Одни проблемы с ним - лишний слой сопровождать.

> Но последний тоже вопросов юзеру не задавал, ибо был сервисом

А кто задавал юзеру вопросы ?

← →
clickmaker © (2008-01-30 13:18) [27]

> А кто задавал юзеру вопросы ?

тонкий клиент

← →
clickmaker © (2008-01-30 13:22) [28]

> В процессе обработки возникает проблема, вариант решения
> которой неплохо было бы уточнить у пользователя

а что, кстати, за проблема?
просто интересно

← →
ANB © (2008-01-30 13:37) [29]

> а что, кстати, за проблема?

Ну один пример я уже написал выше.

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

← →
clickmaker © (2008-01-30 13:41) [30]

а, то есть это?

> В процессе выясняется, что на счете возникает красное сальдо.
> В старой системе пользователя справшиваем - чего с ним делать.
> Т.е. отменить регистрацию, заболтить на проблему, поставить
> документ на картотеку (и некоторые параметры картотеки).
> Причем алгоритмизировать выбор не получается (иначе бы сразу
> так сделали), т.е. юзер по ему известным причинам может
> выбрать любой вариант.

а нельзя предварительно некие настройки завести, типа такого:
что делать, если возникает красное сальдо:
(*) заболтить
( ) отменить регистрацию
( ) поставить документ на картотеку
-- Параметры картотеки --------

---------------------------------
или там все сильно зависит от конкретного документа?

← →
ANB © (2008-01-30 13:44) [31]

> или там все сильно зависит от конкретного документа?

Вот именно это. Иначе давно бы от диалога и на клиенте избавились.
Оператор чешет репу, спрашивает буха и они принимают решение в зависимости от крутости клиента и погоды в Гватемале.

← →
clickmaker © (2008-01-30 13:51) [32]

> [31] ANB © (30.01.08 13:44)

вот здесь бы как раз и пригодился сервер приложений.
Поскольку в нем легче организовать обратную связь.
Я делал, но не вопросы, а оповещение о некоем событии. Только отказался от глючных ConnectionPoints, а делал через mailslot

← →
Sergey13 © (2008-01-30 13:52) [33]

> [31] ANB © (30.01.08 13:44)

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

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

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

> вот здесь бы как раз и пригодился сервер приложений.

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

> [34] ANB © (30.01.08 14:14)

Можно принять, что обработка 1 документа является частным случаем пакетной обработки. Я бы наверное пошел таким путем.

> Sergey13 © (30.01.08 14:44) [35]

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

> как на сервере узнать ИП машины сессии
А так не пойдёт?
utl_inaddr.get_host_address(USERENV("terminal"))

> utl_inaddr.get_host_address(USERENV("terminal"))

Та как то резолвить с сервера обратно не очень. УТЛ_ТСП и сам разрезолвит, если очень надо будет.
Должен же где то оракл у себя ИП клиента хранить по идее.

Нашел

select SYS_CONTEXT("USERENV","IP_ADDRESS") from dual

> да первого файрвола это все

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

> ANB © (30.01.08 16:28) [41]

я б все-таки не мучался, а сделал, например, так:

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

А что произойдет при таком решении если клиент 2 экземпляра ПО запустит?
Или по какой либо причине в терминале, из разных сесий?

Стояла аналогичная проблема. Послали нафиг, так как ораклу ораклово, а юзеру юзерово. Сделал примерно как в [42]

Суть вопроса - надо вводить людей (Фамилия,Имя,Отчество и еще куча половых признаков). Могут встречаться однофамильцы, а могут одну и ту же персону N раз ввести. Вот и надо спросить - мол, а уверен ли ты, что не одного и того же тупо вводишь ?

> я б все-таки не мучался, а сделал, например, так:
>
> хранимка работает себе спокойно в пакетном режиме, обрабатывая
> документы, условно, с флагом "не проведен", доходит до проблемного
> документа, завершается с соотв. кодом.
> клиент этот код анализирует, спрашивает оператора, опять
> запускает хранимку до след. проблемного документа

Дык так ща и делаем. Вот только назвать это "не мучился" очень тяжело. Скорее наоборот.

с вопросами сервер не уйдет в монопольный доступ одному пользователю?
2 хранимки...
первая для одного документа, с транзакциями прочее
вторая для batch обработки документов, вызывает первую for each doc do первая_хранимка, без транзакций и блокировок
+ [42]

← →
ANB (2008-02-01 16:35) [47]

> вторая для batch обработки документов, вызывает первую for
> each doc do первая_хранимка, без транзакций и блокировок

Дык так уже сделано. Вот только документы, по которым нужны уточнения, отбрасываются. Писано уже выше.

> с вопросами сервер не уйдет в монопольный доступ одному
> пользователю?

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

Диалог из оракловой хранимки. Найти похожие ветки