Loosely corresponds to a CellSet. A given statement may be executed several times over its lifetime, but at most one execution can be going on at a time.
@author jhydeThe state of an execution is either active or locked. An active execution is either executing or waiting for an external trigger. If an execution is not in {@link #STATE_ACTIVE_ROOT}or {@link #STATE_ACTIVE_CONCURRENT} then it is locked. A locked execution is read only.
When a new execution is created, it is in {@link #STATE_ACTIVE_ROOT}. {@link #STATE_ACTIVE_ROOT Some STATE_* constants} are provided that represent the most commonly used locked states. But the state '...' in the picture indicates that any string can be provided as the state in the lock method.
If an execution is locked, methods that change the execution will throw a {@link JbpmException} and the message will reference the actual locking state.{@link OpenExecution#setVariable(String,Object) updating variables}, {@link OpenExecution#setPriority(int) updating priority} are not considered to change an execution.
Make sure that comparisons between {@link #getState()} and the {@link #STATE_ACTIVE_ROOT STATE_* constants} are done with .equals and not with '==' because if executions are loaded from persistent storage, a new string is created instead of the constants.
The state of an execution is either active or locked. An active execution is either executing or waiting for an external trigger. If an execution is not in {@link #STATE_ACTIVE}, then it is locked. A locked execution is read only.
When a new execution is created, it is in {@link #STATE_ACTIVE}. To change the state to a locked state, use {@link #lock(String)}. {@link #STATE_ACTIVE Some STATE_* constants} are provided that represent the most commonly used locked states. But the state '...' in the picture indicates that any string can be provided as the state in the lock method.
If an execution is locked, methods that change the execution will throw a {@link PvmException} and the message will reference the actual locking state.{@link #fire(String,ObservableElement) Firing events}, {@link #setVariable(String,Object) updating variables}, {@link #setPriority(int) updating priority} and {@link #addComment(String) adding comments} are not considered to change an execution. Also {@link #createExecution(String) creation} and {@link #removeExecution(Execution) removal} of child executions are unchecked, which means that those methods can be invoked by external API clients and node behaviour methods, even while the execution is in a locked state.
Make sure that comparisons between {@link #getState()} and the {@link #STATE_ACTIVE STATE_* constants} are done with .equals and not with '==' because if executions are loaded from persistent storage, a new string is created instead of the constants.
A client request, e.g., HttpServletRequest, might consist of multiple ZK request ( {@link org.zkoss.zk.au.AuRequest}). However, these ZK requests must target the same desktop of pages ( {@link Page}).
Because a request might come from HTTP or other protocol, Execution also serves as an isolation layer. @author tomyeh @see Page
Ratpack is non blocking. This requires that IO and other blocking operations are performed asynchronously. In completely synchronous execution, the thread and the call stack serve as the representation of a stream of execution, with the execution being bound to a single thread exclusively for its entire duration. The {@code Execution} concept in Ratpack brings some of the characteristics of the traditional single-thread exclusive modelto the asynchronous, non-exclusive, environment.
A well understood example of a logical stream of execution in the web application environment is the handling of a request. This can be thought of as a single logical operation; the request comes in and processing happens until the response is sent back. Many web application frameworks exclusively assign a thread to such a stream of execution, from a large thread pool. If a blocking operation is performed during the execution, the thread sits waiting until it can continue (e.g. the IO completes, or the contended resource becomes available). Thereby the segments of the execution are serialized and the call stack provides execution context. Ratpack supports the non-blocking model, where threads do not wait. Instead of threads waiting for IO or some future event, they are returned to the “pool” to be used by other executions (and therefore the pool can be smaller). When the IO completes or the contended resource becomes available, execution continues with a new call stack and possibly on a different thread.
The execution object underpins an entire logical operation, even when that operation may be performed by multiple threads.
Importantly, it also serializes execution segments by way of the {@link ratpack.exec.ExecControl#promise(ratpack.func.Action)} method.These methods are fundamentally asynchronous in that they facilitate performing operations where the result will arrive later without waiting for the result, but are synchronous in the operations the perform are serialized and not executed concurrently or in parallel. Crucially, this means that state that is local to an execution does not need to be thread safe.
The execution object actually underpins the {@link ratpack.handling.Context} objects that are used when handling requests.It is rarely used directly when request handling, except when concurrency or parallelism is required to process data via the {@link ratpack.handling.Context#exec()} method.Moreover, it provides its own error handling and completion mechanisms.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|