|
Разрешить пользователям только 1 сеанс
|
|||
---|---|---|---|
#18+
Добрый день! Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options Application Express 4.1.0.00.32 Авторизация и аутентификация пользователей настроена через стандартный механизм Апекса: Home -> Administration -> Users Проблема в том, что один пользователи бывают нетерпеливыми и нервными. Не дождавшись загрузки отчета, пытаются снова его сформировать. В итоге, один пользователь может наплодить одинаковых активных сессий. Выглядит это так: APEX_PUBLIC_USER PETROV APEX_PUBLIC_USER SIDOROV APEX_PUBLIC_USER IVANOV APEX_PUBLIC_USER IVANOV APEX_PUBLIC_USER IVANOV APEX_PUBLIC_USER IVANOV APEX_PUBLIC_USER IVANOV APEX_PUBLIC_USER IVANOV APEX_PUBLIC_USER IVANOV APEX_PUBLIC_USER IVANOV APEX_PUBLIC_USER IVANOV То есть, от ораклового пользователя APEX_PUBLIC_USER, выполняются активные сессии от 3-х пользователе Апекса (PETROV, SIDOROV, IVANOV). Но Иванов нервничает, тыркает по кнопкам, из-за того, что у него "долго грузятся отчеты" - плодит активные сессии, которые еще больше грузят сервер и усугубляют ситуацию. Как сделать, чтобы оракловый юзер не мог плодить сессии - понятно (через профайл). Но как сделать, чтобы от одного ораклового юзера могло работать сразу несколько разных апексовых пользователей? И как сделать, чтобы один апексовый пользователь не мог плодить несколько активных сессий? Может ли кто-нибудь подсказать или ткнуть, где написано? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2012, 16:07 |
|
Разрешить пользователям только 1 сеанс
|
|||
---|---|---|---|
#18+
LlanowarКак сделать, чтобы оракловый юзер не мог плодить сессии - понятно (через профайл). Первое, что приходит в голову - сделать авторизацию и аутентификацию через пользователей БД. Задача сводится к предыдущей... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2012, 17:46 |
|
Разрешить пользователям только 1 сеанс
|
|||
---|---|---|---|
#18+
Llanowar, Не позволяет апекс управлять созданием своих сессий. Зато можете определить поведение Duplicate Submission в свойствах страницы. И/Или не давать пользователю повторную отправку см. apex.submit + showWait ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2012, 18:01 |
|
Разрешить пользователям только 1 сеанс
|
|||
---|---|---|---|
#18+
rockclimber, Коннектится все равно будет под APEX_PUBLIC_USER, хоть какая там аутентификация и авторизация, так что не свести её к предыдущей задаче. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2012, 18:12 |
|
Разрешить пользователям только 1 сеанс
|
|||
---|---|---|---|
#18+
Llanowar, Во время выполнения процесса показывать пользователю прогресс бар + сделать недоступными остальные элементы на странице. Похоже сделана операция импорта приложения в самом апексе. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2012, 18:30 |
|
Разрешить пользователям только 1 сеанс
|
|||
---|---|---|---|
#18+
haXbatсделать недоступными остальные элементы на странице. Похоже сделана операция импорта приложения в самом апексе. Поддерживаю. В нашем случае было еще хуже - данные успевали отправиться дважды, а ответ приходил небыстро. Поскольку то был инсерт, ситуация получалась плачевной. Блокируйте элементы. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2012, 11:19 |
|
Разрешить пользователям только 1 сеанс
|
|||
---|---|---|---|
#18+
Коллеги, спасибо за ответы! Пока что сделал так: Template Footer: Код: javascript 1. 2. 3. 4. 5. 6. 7. 8. 9.
Template header: Код: javascript 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Button URL: javascript:html_Submit_Progress(this); В результате видно прогресс бар. Все остальное неактивно :) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2012, 17:52 |
|
Разрешить пользователям только 1 сеанс
|
|||
---|---|---|---|
#18+
LlanowarПроблема в том, что один пользователи бывают нетерпеливыми и нервными. Не дождавшись загрузки отчета, пытаются снова его сформировать. Проблема в неблокирующем создании отчёта. А решать Вы почему-то стали через сессии... А потом и вовсе через блокирование интерфейса. Которое не помешает пользователю открыть ещё раз страницу в соседней вкладке или обновить эту же. Сделайте собственный механизм блокировок. Сохраняйте где-нибудь признак того, что идёт расчёт/создание отчёта и т.п., проверяйте этот признак перед длительным действием. Переменная в сессии, строка в таблице или коллекции, глобальный контекст. Если не установлено — создание отчёта, установлено — сообщение пользователю, блокирование/скрытие кнопок. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2012, 04:29 |
|
Разрешить пользователям только 1 сеанс
|
|||
---|---|---|---|
#18+
suPPLer, Спасибо за наводку. Попробую сделать, как появится время. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2012, 19:37 |
|
Разрешить пользователям только 1 сеанс
|
|||
---|---|---|---|
#18+
suPPLer, приветствую. ОФФТОП, но выйдите пожалуйста на связь любым доступным способом :) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.10.2012, 06:14 |
|
Разрешить пользователям только 1 сеанс
|
|||
---|---|---|---|
#18+
Тогда вместо механизма блокировок лучше сделать полностью асинхронное получение отчётов. Пользователь ставить в очередь запрос на отчёт, по расписанию запускается процедура, которая генерирует отчеты на основе запросов из очереди, а пользователь потом может через какое-то время загрузить любой из сгенерированных отчётов. Примерно как в SQL Workshop-SQL Scripts есть скрипты запускаются в background. Но если всё дело лишь в том, что пользователь много кликает мышкой, то javascript - идеальный вариант ... |
|||
:
Нравится:
Не нравится:
|
|||
29.10.2012, 21:26 |
|
|
start [/forum/topic.php?fid=50&msg=38006186&tid=1875942]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
42ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 292ms |
total: | 434ms |
0 / 0 |