This topic describes the hierarchical relationship between
transaction and ActivitySession contexts. This relationship, defined
by the ActivitySession service, requires that any transaction context
be either wholly inside or wholly outside an ActivitySession context.
An ActivitySession context is very similar to a transaction context
and extends the lifecycle choices for activation of enterprise beans;
it can encapsulate one or more transactions. The ActivitySession context
is a distributed context that, like the transaction context, can be
bean- or container-managed. An ActivitySession context is used mainly
by a client to scope the lifecycle of an enterprise bean that it uses
either beyond or in the absence of individual transactions started
by that client.
ActivitySessions have a lower overhead than transactions and can
be used instead of transactions that are only used to scope the lifecycle
of a called enterprise bean. For a bean with an activation policy
of ActivitySession, the duration of any resource manager local transactions
(RMLTs) started by that bean can be bounded by the duration of the
ActivitySession instead of the bean method in which the RMLT was started.
This provides flexibility and potential for using RMLTs in an enterprise
bean beyond the scenarios described in the J2EE specifications. The
J2EE specifications define that RMLTs need to be completed before
the end of the bean method, because the bean method is the only containment
boundary for local transactions available in those specifications.
The following rules defines the relationship between transactions
and ActivitySessions.
- The EJB or Web container always uses a local transaction containment
(LTC) if there is no global transaction present. An LTC can be method-scoped
or ActivitySession-scoped.
- Before a method dispatch, the container ensures that there is
always either an LTC or global transaction context, but never both
contexts.
- ActivitySessions cannot be nested within each other. Any attempt
to start a nested ActivitySession results in a com.ibm.websphere.ActivitySession.NotSupportedException
on UserActivitySession.beginSession().
- An ActivitySession can wholly encapsulate one or more global transactions.
- The application can end an ActivitySession with an operation to
either checkpoint or reset all resources. The endSession(EndModeCheckpoint) operation
checkpoints the work coordinated under the ActivitySession then ends
the context. The endSession(EndModeReset) operation
resets, to the last point of consistency, the work coordinated under
the ActivitySession then ends the context.
- An ActivitySession cannot be encapsulated by a global transaction
nor should ActivitySession and global transaction boundaries overlap.
Any attempt to start an ActivitySession in the presence of a global
transaction context results in a com.ibm.websphere.ActivitySession.NotSupportedException
on UserActivitySession.beginSession(). Any attempt
to call endSession(EndModeCheckpoint) on an ActivitySession
that contains an incomplete global transaction results in a com.ibm.websphere.ActivitySession.ContextPendingException.
Neither the global transaction nor the ActivitySession context are
affected. If endSession(EndModeReset) is called
then the ActivitySession is reset and the global transactions marked
rollback_only.
- Each global transaction wholly encapsulated by an ActivitySession
is independent of every other global transaction within that ActivitySession.
A rollback of one global transaction does not affect any others or
the ActivitySession itself.
- ActivitySession and global transaction contexts can coexist with
an ActivitySession encapsulating one or more serially-executing global
transactions.
- EJB home methods cannot participate in an ActivitySession because
this situation might cause deadlocks. EJB home methods run in their
own independent LTC.