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 depending on the execution context. For example, if the action is called as the handler of some event on a form (the most common case), then the session of that form will be the current session for it. The current session may also change when the new session operator is used, for example.
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.
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.