I'm looking for suggestions for the following scenario:

When a user logs in, he gets an initial page, which contains a graph - an img tag pointing to a gif dynamically produced by a servlet. The data for the graph will typically take 2-3 seconds to load from the backend system -the access is wrapped inside a stateless EJB.

To lower the wait time for the user, we would like to initiate the request when the page is accessed and not wait until the browser requests the gif. However, we do not want to wait for it to finish before returning the page. In effect, we want a we cache which we can tell "we will need these data soon".

The non-J2EE equivalent would be to kick off a worker thread to fetch the data and then have the image request wait() for the result to be available.
However, we do want to stay within J2EE. Our current idea is:

1. When the first page request comes in, we send a JMS message with the data request to a request queue, and store the JMS message id in the HttpSession.

2. We have an MDB listen to the request queue, get the message, retreive the backend data and publish the result to a response queue using the initial message id as correlation id.

3. When the image request comes in, get the message id from the session and receive the data from the response queue using a message filter based on the correlation id. In this way, we will wait for the data if it is not yet available.

The design does seem somewhat clumsy. One of the main problems is that the MDB will not run with the correct principal.

Are there any patterns I should be aware of? Any possibilites which I have overlooked? Any risks in this design?