Often implementing function
wins out over responsible use of resources. A typical Web transaction is performed through
a GET or a POST to a servlet or CGI. The servlet or CGI processes the request and returns
a response. In many ways this is linear programming. If you use message queuing systems
in your Web applications today, then you might already know the wonders of responding
without necessarily completing the entire transaction. To help illustrate this design point,
BluePages offers a couple of examples, all based on the same pattern.
One of the design criteria for the online administration page was to track operation statistics
in real-time: Who were the last ten users to log-in (success/failure), what were the last ten
searches, and so forth. One of the more costly aspects of collecting such performance statistics
is that it takes cycles away from performing the user facing operations. The problem
to solve was how to perform the tasks as part of a transaction without constantly having
a locked state around a data structure, or processing requests while we should be sending
back results.
The basic solution is based around a blocking queue design pattern (Grand, 2002; Kabutz,
2001) dequeueing only when there are objects present in the queue.
Pages:
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321