Hi Stephen, On Tue, 19 Nov 2002, Stephen Adkins wrote:
> My question with this approach is not whether it works for synchronous > execution (the user is willing to wait for the results to come back) > but whether it makes sense for asynchronous execution (the user will > come back and get the results later). What kind of interface will you provide to the final users? > In fact, we provide our users with the option: > > 1. fetch the data now and display it, OR > 2. put the request in a queue to be fetched and then later displayed > We have a fixed number of mainframe login id's, so we can only run a > limited number (say 4) of them at a time. So it is possible that an immediate request is queued if the system has already reached its maximum allowed logins. In other words, a final user can request to display data immediately but your middleware can answer that the request has been queued, possibly saying 'your job id, position n, see you later'. Moreover, you must preserve order of requests. And if I recall correctly you talked about a sort of queue listing and some job manipulation. Whatever will be your choice, you undoubtedly need to serialize requests and enqueue them using a dbms. It is the simplest approach. Given a method to add, list or remove requests from this kind of queue, mod_perl (even plain cgi scripts) can use these method to manipulate a user's job. Using access control supplied by Apache, it is possible to give different access rights to users of the middleware. Requests from final users will be always enqueued by an Apache children, that will get a job-id and its position in the queue. If the job is on top of the queue, you will immediately wait for its completion. Otherwise you can tell the user to check his job queue later. Users can remove jobs from the queue. All completed jobs will be stored somewhere (file system and/or db) and can be listed by legitimate users. Jobs completed will show in a separate queue. An external entity will dequeue jobs and process them, probably using something like Parallel::ForkManager to limit concurrent requests. Another entity will enqueue recurring jobs. Jobs scheduled for future processing should always be enqueued immediately, or I can't imagine a coherent interface to remove jobs. These entities look like daemons, that can be spawned and controlled using code executed by Apache. Please note that I never mentioned html, using Apache as your infrastructure you can build whatever interface you need. Requests recorded inside db can also be used to implement a cache, probably reused by following requests. It would be possible to collapse identical requests (to save logins). Obviously it is possible to replace Apache with POE or Stem, but I don't know how, sorry. There are many other solutions, but this sketch describes my way to do it. Sorry for the length of this message. Ciao, Valerio Valerio Paolini, <http://130.136.3.200/~paolini> -------------------------------------------------- Linux, the Cheap Chic for Computer Fashionistas
