Databases Reference
In-Depth Information
Session State Management: A Quick Overview
Most conventional web application architectures are inherently stateless. Simply put, this means that
the data is not retained between subsequent executions. To allow for more complex applications,
though, many web architectures have mechanisms to retain or rejoin to session data so that processing
can occur across page views in what amounts to a single application session or user session.
Oracle APEX approaches this by using a session cookie stored on the user's browser. When a user
first instantiates a session in an APEX application, a session cookie is placed on the user's computer.
When that user attempts to access the same application again with a valid cookie, APEX recognizes the
returning user and makes that user's session data available. A simple example of how this would be
useful is a multiple page survey that collects information from a user.
Imagine a user, John, is entering information into a web survey written in APEX. When John enters
his name into an item on the first page,
P1 NAME
, and then clicks to the next, his name appears at the top
of the second page in the form of static text, for example, “John's Survey Responses, Page 2”. APEX was
aware that it was John accessing the second page and not some random user because, behind the
scenes, it recognized the valid session cookie and made that session's value of P1_NAME available to the
application. It is certainly possible to manage this non-trivial logic on your own, but APEX does this
incredibly efficiently and seamlessly for you. Later on, when the user's session has been inactive for a
significant period of time, APEX even purges the older data so that unnecessary values like
P1 NAME
aren't
store beyond their usefulness.
Session State Managed Tables
Similar to the way APEX handles session data for page and application-level items, APEX Collections
allow developers an easy way to share data across page views without having to check for cookies and
rejoin session data. In this sense, APEX Collections can be thought of as tables that automatically
provide session state management. With this concept in mind, we can take a deeper look into the logical
workings of the traditional shopping cart example that so often is associated with APEX Collections.
Logically Walking Through a Web Shopping Cart Implementation
If you built an APEX application to serve as a store for online purchases, you would need a way to track
some basic information about the items being purchased by users as they browse your store. To have
this data available at checkout time, you need to tie the data to the users' session in some way. Earlier,
we walked through the example of a single APEX item,
P1 NAME
, whose data persists across user session
page views, and this might meet your needs if your customers were only allowed to buy one book per
store visit—however, that's an unlikely rule. To store information about the unknown number of items
your customers might buy, you would want to create a collection storing information like the product
description, price, and quantity purchased. This way, as the user clicked between pages of your online
store, APEX would automatically recognize returning users and make their shopping cart available each
time. At checkout, you could take the information gathered in the collection, process it as necessary, and
store the relevent details in some sort of Orders table. To avoid clutter, you could then drop the
collection—but if you overlooked this advisable course, APEX would handle the purging for you at a later
time.
A Look Under the Covers
Before actually discussing APEX Collection use cases and techniques, it is worthwhile to take a quick
peek into the APEX engine to see how collection data is stored and made available to developers. As
mentioned earlier, APEX collections are in fact stored in regular database tables. Once this data is stored,
