Change sessions

Actions can change the state of the system in which they are executed. It is not always desirable to write these changes directly to the database, both from the perspective of integrity and from the perspective of the ergonomics of the system. The platform therefore allows to accumulate these changes locally in change sessions.

Changes in a session may be changes in data properties, including local ones, as well as changes in classes of objects. The former are done by actions created using the property change operator, the latter using the add/change object class operators.

Each time an action is executed, the current session is determined by the execution context: for an action invoked from a form (the most common case) the form's session becomes its current session; for a nested call the caller's current session is inherited; for a top-level invocation (scheduler, event handler, remote call) the session is supplied by the platform when the action is dispatched. The current session can also be replaced for the inner action by the new session operator.

If an action refers to some property during the execution, then its value is calculated taking into account the changes made in the current session of that action.

Two basic operations are supported for a session — application and cancellation — as well as a set of operators for working with changes (including getting a previous value in the session).

Note that change sessions are not thread safe, therefore when using operators that explicitly or implicitly perform actions in a new thread and do not block their execution flow, it is highly recommended not to access the current session after they are executed (such "multi-threaded" operators include the new thread and asynchronous form opening operators). In this case, it is recommended that you always create a new session.