This topic describes how a Web application that runs in
the WebSphere® Web container can participate
in an ActivitySession context.
If the Web application is designed such that several servlet
invocations occur as part of the same logical application, then the
servlets can use the HttpSession to preserve state across servlet
invocations. The ActivitySession context is one state that can be
suspended into the HttpSession and resumed on a future invocation
of a servlet that accesses the HttpSession.
An ActivitySession
is associated automatically with an HttpSession, so can be used to
extend access to the ActivitySession over multiple HTTP invocations,
over inclusion or forwarding of servlets, and to support Enterprise JavaBeans (EJB) activation periods that
can be determined by the lifecycle of the Web HTTP client. An ActivitySession
context stored in an HttpSession can also be used to relate work for
the ActivitySession back to a specific Web HTTP client.
The
Web container manages ActivitySessions based on deployment descriptor
attributes associated with servlets in the Web application module.
The two usage models are:
- The Web container starts and ends ActivitySessions.
The Web
application invokes a servlet that has been configured for container
control of ActivitySessions.
- If an HttpSession exists then it has an associated ActivitySession.
- If an HttpSession does not exist, the servlet can start an HttpSession,
which causes an ActivitySession to be started automatically and associated
with the HttpSession.
A servlet cannot start a new HttpSession until an existing
HttpSession has been ended. Within an HttpSession, the Web application
can invoke other servlets that can use the associated ActivitySession
context. When the Web application invokes a servlet that ends the
HttpSession, the ActivitySession is ended automatically. This is shown
in the following diagram:
Figure 1. Web container control of
ActivitySessions.
This figure is described in the surrounding
text.
- The Web application starts and ends ActivitySessions.
The Web
application invokes a servlet that has been configured for application
control of ActivitySesions.
- If an HttpSession exists and has an associated ActivitySession,
the servlet can use or end that ActivitySession context.
- If an HttpSession does not exist, the servlet can start an HttpSession,
but this does not automatically start an ActivitySession.
- If an HttpSession exists but does not have an associated ActivitySession,
the servlet can start a new ActivitySession. This automatically associates
the ActivitySession with the HttpSession. The ActivitySession lasts
either until the ActivitySession is specifically ended or until the
HttpSession is ended.
The servlet cannot start a new ActivitySession until an
existing ActivitySession has been ended. The servlet cannot start
a new HttpSession until an existing HttpSession has been ended.
Within
an HttpSession, the Web application can invoke other servlets that
can use or end an existing ActivitySession context or, if no ActivitySession
exists start a new ActivitySession. When the Web application invokes
a servlet that ends the HttpSession, the ActivitySession is ended
automatically. This is shown in the following diagram:
Figure 2. Web
application control of ActivitySessions,.
This figure
is described in the surrounding text.
A Web application can invoke servlets configured for either
usage model.
The following points apply to both usage models:
- To end an HttpSession (and any associated ActivitySession), the
Web application must invalidate that session. This causes the ActivitySession
to be checkpointed.
- Any downstream enterprise beans activated within the context of
an ActivitySession can be held in memory rather than passivated between
servlet invocations, because the client effectively becomes the Web
HTTP client.
- Web applications can be composed of many servlets, and each servlet
in the Web application can be configured with a value for ActivitySessionControl.
ActivitySessionControl determines whether the servlet or its container
starts any ActivitySessions.
- An ActivitySession context that encapsulates an active transaction
context cannot be associated with an HttpSession, because a transaction
can hold database locks and should be designed to be shortlived. If
an application moves an active transaction to an HttpSession, the
transaction is rolled back and the ActivitySession is suspended into
the HTTPSession. In general, you should design applications to use
ActivitySessions or other constructs as the long-lived entities and
ACID transactions as short-duration entities within these.
- Only one ActivitySession can be associated with an HttpSession
at any time, for the duration of the ActivitySession. An ActivitySession
associated with an HttpSession remains associated for the duration
of that ActivitySession, and cannot be replaced with another until
the first ActivitySession is completed. The ActivitySession can be
accessed by multiple servlets if they have shared access to the HttpSession.
- ActivitySessions are not persistent. If a persistent HttpSession
exists longer than the server hosting it, any cached ActivitySession
is terminated when the hosting server ends.
- If the HttpSession times out before the associated ActivitySession
has ended, then the ActivitySession is reset1.
This rolls back the ActivitySession resources to the last point of
consistency:
- If the Web application invoked a servlet that has been configured
for container control of ActivitySessions, the ActivitySession resources
are rolled back completely.
- If the Web application invoked a servlet that has been configured
for application control of ActivitySessions, the ActivitySession resources
are rolled back to the last checkpoint taken by the servlet, or completely
if no checkpoint has been taken.
- If the ActivitySession times out, it is reset to the last point
of consistency (see previous item), then the HttpSession is ended.
1 Resetting an ActivitySession
causes all the resources involved in the current ActivitySession to
be rolled back to the last point of consistency, but allows further
work within the ActivitySession. When the reset completes, the thread
is associated with the same ActivitySession as it was before the reset
was called. The ActivitySession resources remain associated with the
ActivitySession although they cannot participate further in the ActivitySession