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 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:
- 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:
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 EJBs 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.