This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi, 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! Jeroen
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. Bill
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.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Sep 12, 2002
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.