ActivitySession and transaction contexts
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 EJB specifications. The EJB 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
containing 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-running 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.
Related concepts
Concept topic