Server Smalltalk Guide

Transactors

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.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]