File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Servlets and the fly likes Sequential request processing Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Sequential request processing" Watch "Sequential request processing" New topic

Sequential request processing

J.H.B. Oosterlaar
Ranch Hand

Joined: Sep 12, 2002
Posts: 41
I need to process request data on the FIFO (first in first out) basis. The only way to be sure that the requests are handled in order of arrival, is to process the requests sequentially.
A pre-instantiated Servlet has a global action object that handles the request. The service method call a perform() method of that action, giving the request and response contexts as arguments. This way each request is handled sequentially. The action object stores the handled request as a bean in a queue. Another concurrent process dequeues for further processing. This concurrent process needs the queue elements in order of arrival.
I want to know whether this is acceptable or not. I don't see any other solution.
Thanks in advance!
William Brogden
Author and all-around good cowpoke

Joined: Mar 22, 2000
Posts: 13037
Sounds to me like a reasonable approach but I'm not clear on your use of "another concurrent process". Why start another Thread?
I first thought "why not make your service method synchronized, that way only one request could be processed at one time" but then I realized that you can't control the order in which waiting Threads get access.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17421

You really didn't day enough about the source(s) of the requests. Network latency and other such things make it pretty much impossible to guess what order requests will arrive relative to the times they were sent out, so you'd definitely need additional support if you're getting requests from multiple sources.
If all the requests came from a single source, there's no problem. HTTP is request/response, so before you send the next request, you have to have received the precceding response.
In the case of heavy back-end processing, I prefer to allow for the possibility of running multiple concurrent backend processes. Request ordering can't meaningfully apply in cases like that.
In some cases, the original timing of the requests doesn't actually matter, but an ordering has to be imposed. For example, when handing out ticket numbers for jobs. This is something that can be handled by an EJB, since EJB method access is serialized.

An IDE is no substitute for an Intelligent Developer.
J.H.B. Oosterlaar
Ranch Hand

Joined: Sep 12, 2002
Posts: 41
Well, it's not that I need to know the exact time of arrival. The time of arrival at the Servlet is important.
The situation is as follows: the HTTP requests comes in. The Servlet handles the requests sequential and puts some information retrieved from the request in a bean and enqueues the bean in a queue. Another process running besides the Servlet dequeues the queue and handles the beans: storing the information in the database. This way requests can be handled quickly, without having to wait for storage with its business logic.
Well, the points is that the other process' business logic retrieves the last request of a certain group from the database to check some things with its current handled request. If the request handles was to be concurrent, then I could never be sure, that there wouldn't be a older request still coming. I need to be sure requests of a certain group follow eachother in order of arrival.
I agree. Here's the link:
subject: Sequential request processing
jQuery in Action, 3rd edition