SST supports different transaction systems, such as CICS and Encina. You can use the following when developing transactional systems with SST:

Transactions are objects which model the transactional concept from an underlying transaction service such as CICS or VAP. SST does not implement the middleware but rather enables its use from Smalltalk. As such, SST transactions wrapper the underlying mechanisms. They support the basic begin/commit/abort protocols but make no attempt to mask or modify the transactions server's semantics. Where enhanced capabilities such as nested transactions are available, SST exposes them through platform-specific transaction classes.

While transactions are uniquely associated with individual threads of control (for example, Smalltalk processes), they do not execute code themselves. They are maintainers of context, much the same as the CORBA OTS current object or the MS Transaction Server context object. As in these systems, SST maintains the notion of a current transaction and associates that with the currently executing thread/process (see the sstCurrentTransaction instance method of ProcessorScheduler).

While transactions are explicitly available, you typically manipulate them implicitly through transactional code. Transactional code is code executed in the context of some transaction. Regions of code at different levels of granularity can be transactional:

Note that SST's definition of the term transactional object differs from that of CORBA's OTS. In CORBA a transactional object is simply one which inherits from TransactionalObject and so ensures that any existing transaction context is passed along when the object is invoked. SST's transactional objects are objects whose methods are transactional and so manage the executing transaction context according to the code's transaction mode.

Whenever execution enters a section of transactional code, SST ensures that the current state of the transaction system conforms to the transaction mode specified for the code segment. For example, if a block of code is marked as soft transactional then on entering the code, SST automatically creates a new transaction if there is no current transaction. If there is a current transaction then it is used as the context for the transactional code.

SST exposes the following transaction modes:

Transactors are related to both transactions and Actors. You use them to model high-level application transactions as opposed to low-level data transactions. Typically an application transaction consists of a number of related operations (such as data transactions) glued together by domain logic. For example, allocating an order number, filling in an order and then submitting the order go together to model the "customer purchase" business transaction.

In many cases, the operations in an application transaction can be carried out concurrently. In other cases, the operations must obey transactional rules. Transactors provide the mechanisms and infrastructure for managing collections of transactions and their explicit or inherent concurrency. Furthermore, since some application logic consists of combinations of high-level transactions, Transactors can be nested to form higher-level Transactors. This capability is derived from Actors.

In general then, Transactors facilitate the description and control of high-level application transactions by supporting the coordination and management of a series of operations which may be concurrent or transactional.

Transactors are both a kind of Actor and a manager of actual transactions as supplied by some transactional mechanism. That is, internally, they maintain their own processing resources (Smalltalk processes) which execute within real transactions. In this way the Transactor has complete control over concurrent accesses to local state while the transaction service manages shared external state.

All Transactor methods are automatically transactional code. So not only is the code guaranteed to be executed by one of the Transactor's processes but it will also be evaluated within a real transaction according to the code's transaction mode.

Transactors may themselves be transactional objects (for example, have transactional methods) or may simply execute some transactional code in some internal object or method. Transactors own all transactions executing on their active threads. Since transactions can only be associated with one thread at a time, they can only be associated with one Transactor.

Just as with Actors, Transactors created during execution of some other Transactor must specify whether they are new top-level Transactors or are nested within the current Transactor. A transaction within one Transactor cannot migrate to another Transactor due to the restriction that transactions be associated with only one thread.

The failure of individual operations within a business/application transaction (Transactor) does not imply the failure of the entire business transaction. Note that at any time the application logic may dictate that the business transaction should fail and that all current operations stop. There is however, no general requirement that completed operations (transactions) should be undone. If this is the case then you must encode this logic in the application code.