Влияет ли наличии настройки shared server (разделяемых сессий) на код приложения? Например, если клиент выполняет команду alter session set ..., после чего эта сессия обрабатывает запрос другого клиента, который не в курсе, что предыдущий выполнил alter session set... и это приводит к ошибке?

При dedicated server сессия может навредить только сама себе. Ужесточаются ли требования к разработке при включении shared server?

tru55Если один серверный процесс обрабатывает запросы нескольких сессий, это вовсе не значит, что сессии зависимые или "разделяемые".

Можно подробнее. Если есть 10 серверных процессов, которые обрабатывают поступающие во входящую очередь запросы. Допустим, формат даты по-умолчанию dd.mm.yyyy. Один из SQL в очереди меняет его на yyyymmdd. Этот запрос берет один серверных процессов и выполняет его. После этого у 9 серверных процессов будет формат даты dd.mm.yyyy, а в одного - yyyymmdd ? Или по-другому работает?

То есть в случае, если есть 100 пользователей, они устанавливают 100 сессий к БД, и эти 100 сессий обслуживают 10 серверных процессов. Для каждой из ста сессий в БД находится свои собственные настройки, которые меняются через alter session и они никак не смешиваются. Например, одна из сессий включает трассировку и делает запрос. Этот запрос обрабатывается через серверный процесс с учетом включенной трассировки для данной сессии. После этот же серверный процесс будет выполнять запрос уже от другой сессии и так как в ней не включена трассировка, он не делает трейс. То есть серверный процесс связывает поступивший запрос в очереди с окружением сессии, которая этот запрос отправила, а следующий запрос для другой сессии связывает уже с ее окружением правильно?

Спасибо за ответы, теперь понятно, что и при shared и при dedicated варианте каждая сессия влияет только на себя.

А при варианте, когда появляется промежуточное звено в виде пула установленных соединений с БД, например, web-сервер всегда держит 10 соединений. Пользователи не работают напрямую с базой, только через сервер-приложений. Возможен ли такой сценарий. Разработчик забывает для одного модуля приложения отключить отладку. Пользователь заходит в этот модуль и выполняет запрограммированный код. Этот код через одно из десяти соединений передается на БД, где исполняется, в том числе включается трассировка. После чего это же соединение выполняет запрос уже от другого пользователя, но у него же включена трассировка! То есть все запросы через это соединение будет выполняться с отладкой?

шарит серверshared serverСпасибо за ответы, теперь понятно, что и при shared и при dedicated варианте каждая сессия влияет только на себя.

А при варианте, когда появляется промежуточное звено в виде пула установленных соединений с БД, например, web-сервер всегда держит 10 соединений. /// То есть все запросы через это соединение будет выполняться с отладкой?
Да.
Потому что тут у тебя shared session с точки зрения веб-пользюков.
Хуже того - при типичной степени рукожопости современных веб-разработчиков, последующие будут комитить изменения в базу, на пол-пути отвалившиеся и потому наполовину внесенные кем-то предыдущим.
Короче будет весело.
Но есть лекарство - DRCP.
Посмотри на него пристально.

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

А размер DRCP сделан не для тех, кто не умеет держать пул сессий на сервере приложений самостоятельно? Например apache+php

Вячеслав ЛюбомудровВот с пулом подключений там все не так очевидно

А что там? пул подключений может отслеживать такие события и перед передачей запроса сессии выполнить сброс окружения в дефолтное?