|
|
|
Вопрос по "архитектуре" :)
|
|||
|---|---|---|---|
|
#18+
Добрый день. Есть база 10G, доступ через webdb ( " Код: plsql 1. " ). Бывает, что пользователь запускает(инициирует) долгоиграющее действие (например, долгий запрос). Т.к. подключение ANONYMOUS'a - через shared, то держать сессию не хочется. Возможно, звучит глупо, но как бы создать некую сессию, которой можно было бы передать задание? Напрашивается джоб, но не хотелось бы плодить их много (т.е. возможно больше, чем пользователей). Можно нагородить создание многопоточных процессов через extproc, но может можно как-то проще? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 15:52 |
|
||
|
Вопрос по "архитектуре" :)
|
|||
|---|---|---|---|
|
#18+
vava, Что-то ничего тебе не хочется: ни сессию держать ни джобы плодить. Используй dbms_scheduler, он предоставляет отличные инструменты для мониторинга и управления заданиями. Отработавшее и ненужное подчищай. Хотя счас придет Элик и скажет, что dbms_job рулит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 15:58 |
|
||
|
Вопрос по "архитектуре" :)
|
|||
|---|---|---|---|
|
#18+
Спасибо за ответ. Я далёк от тонкостей SCHEDULER vs DBMS_JOB :) , обычно использую SCHEDULER. Просто не хотел плодить 1000 одновременных джобов, вот и заинтересовался, как же правильно решается проблема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 16:07 |
|
||
|
Вопрос по "архитектуре" :)
|
|||
|---|---|---|---|
|
#18+
vava, 1000 одновременных долгоиграющих. Интересно. Возможно, имеет смысл потюнить перфоманс и не извращаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 16:24 |
|
||
|
Вопрос по "архитектуре" :)
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopvava, 1000 одновременных долгоиграющих. Интересно. Возможно, имеет смысл потюнить перфоманс и не извращаться. Понимаю предположение, но задумываюсь над возможностью совсем уйти от "ожиданий". Кроме того, не только запрос может быть долгим. Например, пользователь может запросить генерацию комплекта каких-нибудь документов (файлов). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 17:49 |
|
||
|
Вопрос по "архитектуре" :)
|
|||
|---|---|---|---|
|
#18+
В целом, проблема отдаленно напоминает необходимость многопоточности в толстом exe-клиенте (чтоб окошко/грид не залипало во время ожидания ответа от БД). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 17:53 |
|
||
|
Вопрос по "архитектуре" :)
|
|||
|---|---|---|---|
|
#18+
vavaкак же правильно решается проблема. Настройкой пула соединений сервера приложений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 17:55 |
|
||
|
Вопрос по "архитектуре" :)
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousvavaкак же правильно решается проблема. Настройкой пула соединений сервера приложений. Имелась ввиду необходимость трехзвенки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 18:16 |
|
||
|
Вопрос по "архитектуре" :)
|
|||
|---|---|---|---|
|
#18+
vavaandrey_anonymousпропущено... Настройкой пула соединений сервера приложений. Имелась ввиду необходимость трехзвенки? Ну webdb уже какбэ трехзвенка. Архитектурно правильно - переползти на сервер приложений и не изобретать велосипед. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 18:23 |
|
||
|
Вопрос по "архитектуре" :)
|
|||
|---|---|---|---|
|
#18+
Да хотелось слоем хранимок обойтись - данные и прочие пайпы всегда рядом. А пул подключений (shared_servers) особо большим не выставишь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 18:31 |
|
||
|
Вопрос по "архитектуре" :)
|
|||
|---|---|---|---|
|
#18+
vavaДа хотелось слоем хранимок обойтись - данные и прочие пайпы всегда рядом. А пул подключений (shared_servers) особо большим не выставишь. Ну если компания готова оплачивать подобные изыскания вместо приведения инфраструктуры с современный вид - то оно, конечно, увлекательно. С другой стороны, я бы постеснялся записать подобный "подвиг" в резюме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2017, 18:33 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39482650&tid=1885665]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
159ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
| others: | 234ms |
| total: | 508ms |

| 0 / 0 |
