Question

I have a Flex web application that uses BlazeDS for a single-channel endpoint (non-secure) communication with a server.

Everything is running fine, and I used BlazeDS pretty much everywhere for sending and retrieving data to/from the server and database. Now I'm writing some new code to retrieve data from the server, but the server has to first process this data and this takes some time (say 5 to 30 minutes depending on the request).

My design pattern up to now has been to show the user a busy cursor and disable the main application (Flex by default blurs out the application when it's disabled). This generally lasts a second or two while the communication completes. However, now the communication takes a long time to complete, and I'd like to be able to have the user continue to use the application even though the process from the server hasn't returned yet.

So what I'd like to do is NOT disable the main application so the user can interact with it while he/she waits for the data to return. The problem I worry about is if the user uses the application to send another process to the server during this time (e.g. before the first process comes back) -- will this cause problems? That is, is BlazeDS smart enough to know the channel is busy and therefore will queue the requests automagically? For example, will BlazeDS wait until the first request comes back before sending the second, or third, etc?

Or do I have to manually control this communication somehow to ensure it occurs in a serial fashion? If so, are there any design patterns to handle this?

Or, can BlazeDS send and get back a second request before the first one returns?

Any advice much appreciated. I'm looking for ways to avoid having the user stare at a unusable application for 5 to 30 minutes waiting for data to return. A busy cursor is fine, because it shows the data has not returned yet, but a disabled main application particularly (whether it's blurred or not) is a problem.

UPDATE:

Here I'm talking about simultaneous calls to different methods, rather than the same method. So if I have two methods, I'd like to call the first method, and while it is waiting to come back, call a second or third method, which return safely before (finally) the first method returns. Is this supported by BlazeDS?

Was it helpful?

Solution

As far as I know, there is no such enqueuing system in blazeDS. But you can configure the concurrency variable :

Value that indicates how to handle multiple calls to the same service. The default value is multiple. The following values are permitted:

multiple - Existing requests are not cancelled, and the developer is responsible for ensuring the consistency of returned data by carefully managing the event stream. This is the default.

single - Making only one request at a time is allowed on the method; additional requests made while a request is outstanding are immediately faulted on the client and are not sent to the server.

last - Making a request causes the client to ignore a result or fault for any current outstanding request. Only the result or fault for the most recent request will be dispatched on the client. This may simplify event handling in the client application, but care should be taken to only use this mode when results or faults for requests may be safely ignored.

So using "single" you can prevent the user to call the same method multiple times

Another solution, if you want to have a more specific control over messages sent to the server is to use the command pattern. Instead of calling many methods, you call only one method en send through the network a command object. You will have more work to do, but it's a good solution if you have some operations that can me done en parallele, and other not

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top