Initializing ⇒ Waiting ⇒ Processing ⇒ Complete

Initializing ⇒ Queued ⇒ Processing ⇒ Complete or Cancelled

When Arbortext PE Request Manager receives a request and is creating the transaction ID and transaction directory, it places the transaction in the initializing state, where it remains while the Arbortext PE Request Manager passes the transaction to each cache manager and queue manager.

The transaction is waiting to be allocated to an Arbortext PE sub-process (for immediate requests).

While a Request Handler attempts to find and allocate an Arbortext PE sub-process willing to process the transaction, the transaction state is set to waiting.

A queued transaction will never enter the waiting state, because an Arbortext PE sub-process is allocated before the transaction would start executing.

The transaction was placed in a queue and is waiting to be executed by the Queued Transaction Scheduler.

If a Queue Manager finds a queue that accepts an incoming request, the transaction state is set to queued.

The transaction is expected to be handled by an Arbortext PE sub-process.

If no Cache manager or Queue Manager supplies a response, the transaction state is set to processing and the transaction is passed to the Request Handlers.

While a Request Handler attempts to allocate an Arbortext PE sub-process, the transaction state is set to waiting. Then it’s set back to processing when the Arbortext PE sub-process, has been allocated.

For queued transactions, the Queued Transaction Scheduler decides when to execute a transaction. When it decides a transaction can be processed, the transaction state changes from queued to processing.

The transaction is finished. A completed transaction can be completed successfully or completed with errors. Note that if the results is an error report rather than the expected document, the transaction is still considered complete.

If a Cache Manager supplies a response to an incoming request, the transaction state is set to complete.

If a Request Handler processes the transaction, or if no Request Handler is able to do so, the transaction state is set to complete.

For a queued transaction, the transaction state changes to complete after it’s processed. If a queued transaction is cancelled, either before execution starts or during execution, its state is set to cancelled

A transaction can also expire while waiting for an Arbortext PE sub-process allocation (if it’s an immediate transaction).

For queued transactions, the transaction has been cancelled.

Before or during the execution of a queued transaction, a transaction may be cancelled by an Arbortext Publishing Engine administrator from the queuing web page or by an f=qt-cancel request. In either case, the transaction state is set to cancelled. If the transaction has not yet started execution, it will never start. If it is running, then its Arbortext PE sub-process will be terminated and a new Arbortext PE sub-process started, if necessary (to satisfy the minimum Arbortext PE sub-process configured in the appropriate Arbortext PE sub-process pool) and the transaction results, if any, will be discarded.

The Arbortext PE Request Manager will fabricate a response for the request and send an HTML page stating that the transaction was cancelled. The cancelled state is like the complete state in the sense that no further processing will be performed.