Maintaining State

To maintain state on a non-virtualized Service, you typically use a field or set of fields in your object to maintain that state. (For C++ or Command Services, state is saved in a slightly different manner.) Because a Service Session can be virtualized on a number of Engines, adjusting a field’s value using a Service request adjusts only that value on the Engine that processed that request. Instead, you must declare the appropriate class method as a stateful method in the Service Type Registry and use the updateState method to guarantee that all Engines update the state. Register all methods used to update the state as such on the Service type, either as one of the setStateMethods or appendStateMethods.

When an Engine processes a Service request, it first processes all update state calls that it has not yet processed, in the order in which they were called on the Service instance. These calls are made prior to the execution of the request. The append value determines whether to make previous update calls. If append is false (a set), all previous update calls are ignored. If append is true, all calls starting from the last set call are performed. Typically, then, append calls update a subset of the state, whereas set calls refresh the entire state. If you intend your Service instance to be a long running state with frequent updates, use a set call on a regular basis so that Engines just coming online do not need to perform a long set of updates the first time they work on this Service instance.

In the case of a task retry when appending state, a task is appended until the correct update state required by the task is reached. Note that this does not occur when using multiplexed Engines — the task receives the most current state.