Tags: developer, explanation

Note

This page has been migrated from the old documentation, and has not yet been fully revised. There might be inconsistencies or errors when using with current LinkAhead versions.

Transactions and Schedules

In LinkAhead, several client requests may be handled concurrently. This poses no problem as long as only read-only requests are processed, but writing transactions need to block other requests. Therefore, all transactions (between their first and last access) block write transactions other than themselves from writing to the backend, while read transactions may happen at any time, except when a write transaction actually writes to the backend.

Note

There is a fine distinction between write transactions on the LinkAhead server and actually writing to the backend, since even transactions which need only very short write access to the backend may require extensive read access before, for example to check for permissions or to check if the intended write action makes sense (linked entities must exist, they may need to be of the correct RecordType, etc.).

The request handling in LinkAhead is organized in the following way:

• HTTP resources usually create a Transaction object and call its Transaction.execute() method. Entities are passed to and from the transaction via TransactionContainers (basically normal Containers, enriched with some metadata).

• The Transaction keeps a Schedule of related Jobs (each also wrapping a specific Transaction), which may be called at different stages, called TransactionStages.

• The Transaction’s execute() method, when called, in turn calls a number of methods for initialization, checks, preparations, cleanup etc. Additionally, the scheduled jobs are executed at their specified stages, for example all jobs scheduled for INIT are executed immediately after calling Transaction.init(). Please consult the API documentation for Transaction.execute() for details.

  Most importantly, the (abstract) method transaction() is called by execute(), which in inheriting classes typically interacts with the backend via execute(BackendTransaction, Access), which in turn calls the BackendTransaction’s BackendTransaction.executeTransaction() method (just a thin wrapper around its execute() method).

Summarized, the classes are connected like this:

There are some core jobs that are always executed. For example, the GenerateEntityId Job causes entity IDs to be set if that is necessary.