Database Reference
In-Depth Information
Figure 6-41. APEX session communication
Sharing Database Connections
Multiple APEX users can share the same database connection. There is a one-to-many
relationship between APEX users and database sessions. This is why APEX can scale
as well as it does—it doesn't need dedicated database sessions, only a database session
to use to process a request from a user.
APEX, being stateless, must rely on an external mechanism to manage session state.
The APEX engine has a built-in session-state management component. This session-
state management is an integral part of APEX—it can't be disabled or circumvented.
Each APEX user is assigned a unique session identifier. Session-state management
functions the same, regardless of how the user authenticates to the system—APEX au-
thentication, database authentication, custom authentication, or public user. Yes, even
unauthenticated users are assigned a session identifier. By default, APEX purges inact-
ive sessions older than 24 hours every 8 hours. APEX session-state values are stored in
a table in the database. The APEX engine recognizes the user by their session identifier
and retrieves the appropriate set of session-state values for the user's session.
The values of all APEX items, both page items and application items, are tied to this
unique session identifier. This identifier is referred to as the APP_SESSION_ID . You
can see the session identifier in the URL of most pages in an APEX application. It's
highlighted in Figure 6-42 .
Figure 6-42. APEX session identifier in an APEX URL
Setting and Retrieving Session State
Session state is set by user-input items, computations, processes, and PL/SQL code. In
PL/SQL, when within an APEX process, you can set an item equal to a value, like so:
 
 
 
Search WWH ::




Custom Search