This release of the Coherence Incubator is now deprecated. For the latest supported release, help and documentation, please refer to the Coherence Incubator Project on java.net at http://cohinc.java.net.
This project provides a generalized approach for submitting and asynchronously processing (ie: executing) "work" in distributed system, based on Oracle Coherence.
The Processing Pattern advocates that;
This implementation of the Processing Pattern additionally advocates that;
This implementation of the Processing Pattern provides a simple and powerful extensible framework for the processing of "work" across a Coherence Cluster. Work can be submitted without needing to know the internals of Coherence or building custom configurations. Unlike the traditional hub-and-spoke / master-worker / broker-agent, the Processing Pattern implementation avoids the classic "single-point-of-failure", "single-point-of-dispatch", "single-point-of-contention" problems as the core state management and distribution is managed by the Data Grid.
Additionally, it provides runtime support to ResumableTasks to enable checkpointing of long running work and a suspend/resume model enabling long running tasks.
Further it supports execution of work based on a run anywhere in the grid paradigm, as well as a more controlled execution model where work is run on specific nodes, either running as grid nodes or over Coherence*Extend.
Version 1.4.4 is a patch release to upgrade dependencies to Coherence Common.
Version 1.4.3 is a patch release to upgrade dependencies to Coherence Common.
Version 1.4.2 is a patch release to upgrade dependencies to Coherence Common.
Version 1.4.1 is a patch release to upgrade dependencies to Coherence Common and to support the up and coming Coherence release.
The most significant upgrade for this release is the adoption of Coherence 3.7. Overtime this will allow the pattern to take advantage of the lastest features, like "lite transactions" to ensure atomicity of multi-cache updates, without the overhead of "heavy" transactions.
* Previous releases are available from the attachments page
Example source code and uses of this pattern can be found in the Coherence Incubator Examples project.
- In order to process work, one or more Dispatchers need to be registered.
- When a dispatcher is registered, each Submission will be handed to each Dispatcher in registration order until
one dispatcher accepts the Submission.
- When a dispatcher has accepted the Submission a SubmissionOutcome is returned to the client.
- When the dispatcher, (or in the case of Task dispatching, the TaskProcessor), has processed the Submission the SubmissionOutcome is signaled and the result is available to the client.
The following diagram illustrates the main structure of the design of the Processing Pattern.
- ResumableTasks are handled by a TaskDispatcher that hooks in to the Dispatcher chain handling Submissions with a ResumableTask as the payload.
- A TaskProcessor executes the ResumableTask.
- Tasks are mapped to TaskProcessors using a configured TaskDispatchPolicy. The default TaskDispatchPolicy matches attributes supplied as part of the SubmissionConfiguration against attributes associated with a TaskProcessor
- When a ResumableTask executes, a TaskExecutionEnvironment is available to support checkpointing, progress reporting and determination of resumption.
- A resumable task can return a special Yield object to suspend execution.
The following diagram illustrates the structure of the Task Execution.
The following diagram illustrates the states a ResumableTask can be in.
The following demonstrates a simple example of the Processing Pattern.