converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 6:||Line 6:|
|Line 11:||Line 11:|
| * [wiki:Self:UseCases/SingleAsyncRequest single asynchronous request]
* [wiki:Self:UseCases/AsyncRequestSequence send a request asynchronously, with automatic follow-up requests]
* [wiki:Self:UseCases/AsyncFireAndForget send a single request asynchronously, forget about the response]
* [wiki:Self:UseCases/MultiAsyncRequests multiple asynchronous requests]
| * [[UseCases/SingleAsyncRequest|single asynchronous request]]
* [[UseCases/AsyncRequestSequence|send a request asynchronously, with automatic follow-up requests]]
* [[UseCases/AsyncFireAndForget|send a single request asynchronously, forget about the response]]
* [[UseCases/MultiAsyncRequests|multiple asynchronous requests]]
|Line 24:||Line 24:|
|Line 35:||Line 35:|
Use Case: Single Asynchronous Request With Response Notification
I want to send a request over a connection without blocking the application.
I want to get a notification when the response is available, so the application does not need to block.
Related / Out of Scope
This use case requires a notification mechanism to indicate availability of a response to the application. Although not strictly required by the description, there should be a way to associate a request with the response for that request. An application could use several connections simultaneously to send a single request on each. The notification mechanism should also provide access to application specific per-request data, to facilitate re-use of a single notification handler for multiple connections and requests.
The requirement for parameters to the notification rules out the use of the generic wait/notify mechanism in java.lang.Object and suggests a callback interface with a method to which parameters can be passed. Error handling can be provided by the same interface, for example as an additional method.
The focus of this use case is the design of an interface for notification. The implementation requires at least one background thread for sending the request, detecting the availability of the response, and notifying the application. One thread may be shared for multiple connections if Java NIO is used, a separate thread for each connections is needed with traditional IO. The responsibility for processing of response headers can be assigned to the application thread, or to the background threads.
The application MUST NOT abuse notification calls by background threads to process responses, interact with the user, or otherwise lock up the thread. Background threads may be needed for other purposes than the notification, even if they are not shared across connections. The callback handler for the notification therefore has to delegate processing to an application thread.