Use this service when you wish to release your application from actively waiting on a synchronous response. Your application can do other things or even shutdown while we execute mutations asynchronously.
Requests to the service will fail if the request was invalid or if any of a job's structural constraints are violated, and depending on the operation, the job will not get created or updated.
Once a job has been submitted, you may check its status periodically, by calling {@link #get}.
Caution: Do not poll the job status too frequently or you will risk getting your customer rate-limited.
Once a job's status changes to {@code COMPLETED}, you can retrieve the job's results.
A job can fail even after it has been accepted for processing. For example, a job may fail if the system experienced too many transient errors. In this scenario, the job will get a status of {@code FAILED} and willstop processing.
The submitted operations are processed in batches for efficiency. Each batch is processed atomically so that either all of them have successful results, or they all fail with a failure result for the entire batch.
Normally, jobs could be processed in parallel. This may cause concurrent mutations to the same entities to fail, though these would be retried later, see below. If you want to serialize the processing of jobs, you could specify prerequisites through the optional {@link JobPolicy}.
You may choose to avoid submitting a new job for mutating an entity while another job for the same entity has not completed yet.
The service will keep retrying operations when transient failures occur. However, if these failures persist for several hours or more serious ones occur, the service will abort a job leaving some or all of its operations unprocessed.
This class was generated by the JAX-WS RI. JAX-WS RI 2.2.4-b01 Generated source version: 2.1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|