public interface RemoteWorkItem extends WorkItem
Clearly, if this is the case then the Work object supplied to scheduleWork cannot be used to interrogate the result when the
Work completes as it was a copy that was executed on the remote JVM. The Work instance is copied and marshalled to the remote JVM
where it is executed and then a copy
of the Work instance is send back to the JVM that called scheduleWork. This returned copy is then available using the
If the application wants to send multiple Work objects to the same remote JVM then it
should schedule Work on a resource-ref obtained WorkManager and then
schedule subsequent Work objects using the WorkManager obtained from the
RemoteWorkItem.getPinnedWorkManager() method. This is called a pinned WorkManager.
This provides affinity to the same remote JVM to be maintained.
If the remote JVM fails then subsequent calls to scheduleWork on the pinned
WorkManager will fail with a
WorkRejectedException once the failure has been detected.
If a remote JVM containing pending Works fails then these Works are marked as complete with a status of rejected.
|Modifier and Type||Method and Description|
This returns a pinned WorkManager which represents the JVM that was used to execute this Work.
Calls the remote Work object's
Work.release()method. It instructs the Work associated with this RemoteWorkItem to 'stop' voluntarily. If the work has already stopped then this has no effect. The
WorkItem.getStatus()can be used to determine whether it has stopped or not but the Work can always stop just after getStatus returns 'still working'. The best way to wait for such Works to release is using the