-
Language:
English
-
Language:
English
Red Hat Training
A Red Hat training course is available for Red Hat JBoss Data Virtualization
A.8. Asynchronous Executions
In some scenarios, a translator will execute asynchronously and allow the executing thread to perform other work. To allow this, it is recommended that a
DataNotAvailableException
is thrown during a retrieval method, rather than explicitly waiting or sleeping for the results.
Note
The
DataNotAvailableException
should not be thrown by the execute method, as that can result in the execute method being called multiple times. The DataNotAvailableException
may take a delay parameter or a Date
in its constructor to indicate when to poll next for results. Any non-negative delay value indicates the time in milliseconds until the next polling should be performed.
The
DataNotAvailableException.NO_POLLING
exception (or any DataNotAvailableException with a negative delay) can be thrown so that processing will resume (via ExecutionContext.dataAvailable()
).
Since the execution (and the associated connection) is not closed until the work has completed, care must be taken if using asynchronous executions that hold a lot of state.
A positive retry delay is not a guarantee of when the translator will be polled next. If the
DataNotAvailableException
is consumed while the engine thinks more work can be performed or there are other shorter delays issued from other translators, then the plan may be queued again earlier than expected. You should throw a DataNotAvailableException
again if your execution is not yet ready. Alternatively the DataNotAvailableException
may be marked as strict, which does provide a guarantee that the Execution
will not be called until the delay has expired or the given Date
has been reached. Using the Date
constructor makes the DataNotAvailableException
automatically strict. Due to engine thread pool contention, platform time resolution, etc. a strict DataNotAvailableException
is not a real-time guarantee of when the next poll for results will occur, only that it will not occur before then.
Note
If your
ExecutionFactory
returns only asynch executions that perform minimal work, then consider having ExecutionFactory.isForkable
return false so that the engine knows not to spawn a separate thread for accessing your Execution
.