Engine Pinning
Engine Pinning enables a Service Session to specify that once an Engine has worked on a Service Session, it cannot work on any other Service Sessions as long as that session is in progress. This enables you to quickly replicate 1-to-1 architectures, or if for legacy reasons or lack of availability to source code to maintain massive amounts of expensive-to-replay state on an Engine.
Typically, you use Engine Pinning in conjunction with Max Engines to limit one or a set of Engines to work solely on a Service.
Engine Pinning is available for any type of Service. It is exposed as two Engine-side methods, pinToService() and unpinFromService(). If an Engine calls pinToService() while working on a task for a Service, it is marked as pinned to the session when it completes the task, regardless of whether the task succeeded. From this point, the Engine takes tasks only from this Service. Once the session finishes, or when the Engine calls unpinFromService(), the Engine is no longer pinned and can work on other Services.
Engines that are pinned are unpinned automatically in the following circumstances:
| • | If the Broker loses its connection with the Engine for any reason (such as loss of heartbeat) |
| • | If the Engine process ends for any reason |
| • | If an Engine performs a soft log off due to Engine Sharing |
| • | If a task fails due to an error in DataSynapse code (such as reading input) |
| • | If the session is destroyed |
Exceptions issued by user code that result in task failure do not cause an Engine to be unpinned unless the exception specifies Engine restart, in which case the above requirement applies.
You can configure Engine balancing so pinned Engines are always reported as busy by Brokers. This prevents the Engine from being shared with other Brokers. This can be configured at Admin > System Admin > Manager Configuration > Engines and Clients, under the Engine Balancing heading, with the Treat Pinned Engines as Busy parameter. This is false by default.
You can implement other pin/unpin strategies—for instance, unpinning after a certain amount of idle time, or when the Broker queue is empty—as a separate Engine thread that polls for a given condition and unpins as necessary.