|
|
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
Здраствуйте! Есть такая задача: Внешнее приложение добавляет в некую таблицу записи. После добавления записи необходимо без задержек ее обработать, т.е. запустить процедуру. Вопрос: как это правильнее реализовать? Пробовал JOB с перодом 1 раз в секунду (проверяет наличие записей и запускает процедуру), но получается задержка ~3-4 сек. Если поставить тригер на insert то увеличивается время добавления записи в таблицу, т.к. процедура долго обрабатывает соотв. записи. В процедуре используются commit и rollback, и это вызывает исключение в тригере. Внешнее приложение должно быстро добавить запись и забыть про нее. Дальнейшая обработка должна осуществляться Oracle. Нужно, что-то типа "triger after commit" на таблицу. Заранее спасибо за ответы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 08:31 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
dbms_alert - извещает ждущую сигнала процедуру при commit. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 09:01 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
А почему бы неиспользовать trigger after insert с автономными транзакциями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 09:12 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
У тебя получаются два взаимно противоречивых условия: - После добавления записи необходимо без задержек ее обработать, т.е. запустить процедуру. - Внешнее приложение должно быстро добавить запись и забыть про нее. Ланчей даром не бывает: либо ты выполняешь все действия в одной транзакции, увеличивая ее время, либо выполняешь те же самые действия по заданию. во втором случае ты можешь, к примеру, job создавать прямо в триггере с nextdate=>sysdate, interval=>null. Но надо быть уверенным, что процесс, который будет его выполнять, "увидит" все требуемые данные, т.е. оти будут зафиксированы в сессии, их изменяющей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 12:24 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
2 Denis Popov. dbms_alert как раз и решает такую задачу. Одна из сессий готовит данные и сигнал, который посылается ждущей сессии при commit'е. Ждущая сессия при получении сигнала просыпается и делает необходимую обработку. Но я бы все-таки использовал AQ или dbms_job для более гибкой работы. В данном случае, триггер неприемлем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 12:32 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
Насколько я знаю, для этого можно использовать так называемые очереди. Об этом в книге Тома Кайта например пишется. Он приводит пример готового чужого проекта, что пользователь вводит данные, потом идёт транзакция длинная для обработки, при этом естественно блокируется интерфейс в ожидании(на 45 сек. кажется). Он переделал это через очередь, при этом юзер спокойно вводит данные не ожидая завершения процедуры обработки. Я так понимаю, это как раз и нужно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 12:35 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
А кто посылает алерт? Всяко не триггер (иначе он же бы полылал commit), а, я думаю, процедура, совершающая обработку? И еще: другая сессия должна постоянно вызвать dbms_alert.waitany или wainone, т.е. заниматься постояным опросом? Если автор топига говорит о 3-4 секундной задержке как о недопустимой, не слишком ли это большие расходы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 12:57 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
waitany/waitone висят и ждут. Их не надо гонять в цикле (хотя можно задавать таймауты ожиданий). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 14:00 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
В любом случае в соседней сессии... Вроде получается 2 подхода: 1. Commit -> Signal Alert. 2. Commit -> Submit Job. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 14:24 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
И что лучше на Ваш взгляд? Alert или Job? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 14:39 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
AQ - advanced queuing. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 14:40 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
Лично я между Alert и Job выбрал вы последнее. Причина- не думаю, что мне бы понравилась сесия, вечно или продолжительное время висящая в ожидании алерта: черт его знает, почему она висит, задание выполняет или просто ждет? Заодно бы читал про AQ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2003, 15:13 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
Задержка получается еще больше!!! Повесил на таблицу тригер: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. JOB Срабатывает через 9 секунд после выполнения тригера??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2003, 11:19 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
За выполнение JOB'в отвечают соответствующие процессы: http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96521/jobq.htm В твоем случае ИМХО можно или поиграться с параметрами JOB_QUEUE_PROCESSES, JOB_QUEUE_INTERVAL, либо делать через алерты. Но учти: для выполнения задания сразу в момент прихода алерта тебе надо обеспечить ситуацию, когда кто-то постоянно его (алерт) ждет. По существу- имитировать работу Job Queues. Заодно представь ситуацию, когда "обработчик" записи- весьма продолжниельна я процедура: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2003, 13:23 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
Вы говорите использовать AQ! т.е. тригер при insert'е помещает задание в очередь с помощью ENQUEUE а кто это задание считывать будет (DEQUEUE)? Как узнать, что в очередь что-то добавилось? И еще, на каждую запись должна запускаться соотв. процедура, и если она ее долго обрабатывает, то остальные записи не должны ждать завершения обработки предыдущей. Т.е. их надо пускать паралельно??? У кого какие мысли по этому поводу??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2003, 08:37 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
Esli ne ustraivaet ni to, no drugoe, to , moget, nado by izmenit' podhod k resheniu tvoei zadachi?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2003, 08:46 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
У меня в проекте почти то, о чем ты говоришь, сделано через Alert'ы. Человек делает проводку товарного документа - при этом в табличку пишется соответств. инфа и посылается алерт. На серваке висит прога, которая ловит этот алерт и запускает нужные процедурины (скорость обработки зависит от многих параметров). И так по циклу. Прога-обработчик выделена отдельно для того, чтобы попутно писать-читать логи, а вообще можно и прям в оракле всё сделать. Т.о. реализована обычная очередь. Параллельности обработки у меня нет, т.к. сложно при одновременной проводке двух док-тов проверять остатки, писать кэши дебиторки и т.п. Конечно, можно переделать на AQ, но как говорится - работает, не трожь :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2003, 08:50 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
Alert, AQ, CORBA etc.. But check Your buisiness-logic! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2003, 09:19 |
|
||
|
TRIGER или JOB?
|
|||
|---|---|---|---|
|
#18+
Ура, получилось!!! Использую AQ. При помещении в очередь проблем нет. Подскажите как теперь их оттуда корректно забирать. Вот этот код работает, но мне надо, чтоб он постоянно висел. (здесь ждет 20 секунд) Для этого я убрал параметр v_DequeueOptions.wait, но кто должен запустить эту процедуру на выполнение??? Может в триггере на StartUp??? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2003, 11:36 |
|
||
|
|

start [/forum/topic.php?fid=52&fpage=2784&tid=1990794]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
27ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
2ms |
| others: | 246ms |
| total: | 380ms |

| 0 / 0 |
