PITMOV,

по-хорошему - никак. Сессии БД у APEX существуют на протяжении отображения или обработки страницы. Пользовательский не глобальный контекст существует на протяжении сессии БД.

В APEX для подобного стоит использовать переменные страницы, переменные приложения и настройки пользователя.

не удержался...,

сорри за поздний ответ.

Да, это именно то, что я назвал "по-хорошему - никак". Потому что PL/SQL-блок, который указывается в Application 110->Shared Components->Edit Security Attributes->Virtual Private Database (VPD), выполняется для каждой страницы. IMHO, в итоге ресурсов на постоянное выполнение этого блока тратится больше, чем на обращение к функции V('ITEM_NAME'). Я проводил грубые тесты: одна небольшая таблица (12 МБ, 100К строк), две вьюхи на неё, одна из них в качестве фильтра использует контекст, вторая - V('ITEM_NAME'). Одно приложение с отчётами по этим вьюхам. Для пяти сессий по 1000 обращений в каждой использование вьюхи с V('ITEM_NAME') было более быстрым, чем установка контекста и использование вьюхи с ним - быстрее процентов на 17-18. На большой нагрузке (например, от 100 сессий) не тестировал, нужно разбираться с каким-нибудь бесплатным генератором тестовой нагрузки типа JMeter.

Если куплена фича VPD, и она уже используется в БД, то APEX даёт лёгкий способ использовать эту фичу, устанавливая необходимый контекст. Для остальных случаев я бы постарался избежать использования этого способа: меньше лишнего PL/SQL выполняется на странице - быстрее время отклика. Я знаю, что это банально, но это работает. :)

англикот,

Вам стоит почитать ссылки в этом посте: 9517461 .

англикотнафига в настройках приложения есть VPD texarea. Как это может быть применимо?

Если у нас уже используется VPD в других проектах, то можно выставлять соответствующие контексты в этом блоке, он будет выполняться при каждом создании страницы.

не удержался...,

дело не в SYS_CONTEXT (отклик действительно быстрый). Дело в выполнении PL/SQL-кода, указанного в блоке VPD. Он выполняется при каждой обработке и отрисовке страницы. Зачем?

Для заново создаваемой VPD можно:
- создать глобальный пользовательский контекст;
- добавить установку соответствующих значений в этом контексте в виде процесса, выполняющегося один раз - при аутентификации пользователя;
- устанавливать и читать значения, используя :APP_USER||':'||:SESSION в качестве CLIENT_IDENTIFIER.

Для старой, уже использующейся в других системах VPD, заточенной под LOGIN, USER и т.п., переделка под глобальный пользовательский контекст может повлечь слишком большие ресурсы. Поэтому APEX даёт возможность использовать эту VPD без переделок, устанавливая контексты в блоке VPD. И этот блок выполняется каждый раз , когда страница обрабатывается или возвращается.

Ещё раз, кратко: дело не в чтении, дело в лишних выполнениях блока PL/SQL-кода.

Ну и поскольку APEX у нас всё-таки "multitiered environment with accessing the databases through connection pools", то небольшой совет из доки:

http://download.oracle.com/docs/cd/B19306_01/network.102/b14266/apdvpoli.htm#i1008538 About Virtual Private Database, Fine-Grained Access Control, and Application Context

Virtual Private Database (VPD) combines server-enforced fine-grained access control with a secure storage of application context values in the Oracle database server. VPD enables you to build applications that enforce row-level security policies at the object level. Policy execution dynamically appends predicates (WHERE clauses) to any SQL statements that query data you have identified as requiring protection.

The application context feature enables application developers to define, set, and access variable-length application attributes and their values. These attributes can then be used as predicate values for fine-grained access control policies. Two types of application contexts exist:

Local (session-based) application context, stored in the UGA and invoked each time an application user connects to the database

Global application context (non-session-based), stored in the SGA and used for multitiered environment users accessing databases through connection pools.

не удержался...suPPLerЕщё раз, кратко: дело не в чтении, дело в лишних выполнениях блока PL/SQL-кода.
если Вы уж так радеете за лишние выполнения PL/SQL кода

Да, радею. Зачем делать лишнее там, где его можно не делать? Я говорю не о смене инструмента, а об соответствующем с ним обращении. Возможно, у меня и у Вас просто разная философия разработки. :)