Doing background processing in a servlet

Question

Hello folks
I'm new here, I wonder if someone can give me an advice in an architecture problem I encountered. This text looks long, but the problem is quite simple � how to allow a servlet to do something independent by the doXXXX() methods invocation.
In my application I have the following two requirements:
1. To allow an HTTP interface, in which user can enter tasks to the server.
2. To allow that the server will handle the tasks by a priority order, whenever their execution time arrives (which is independent by their creation time).
Actually, the server has a priority queue, which contains tasks, and each task has an execution time. The server should wait until the execution time of the closest task (the task that at the head of the queue), and then to execute it, and pop the next task. I've already implemented an application, single threaded, that implements this requirement. The tasks in my application are entered to the queue in the initialization.
The problem begins when I need to add the implement of the first requirement. When a user enters a task, the system should check that maybe the new task becomes the closest, so the waiting time is shorten to the execution time of the new task.
I understood that servlets are an easy to use tool for handling HTTP POST requests, but I also understood that opening a thread is not a good programming, and discouraged. I think I could start a thread of the queue manipulations in the init() method of the servlet, and this thread could handle all the pops from the queue, waits, and execution of tasks. In this implementation each doPost(), will access the queue and add the new task given by the user with the POST request. But as I wrote, I understood that opening a thread by myself in a servlet indicates that the architecture is not good, so I thought about another solution.
My second idea was to use RMI. The queue manipulation, which is already written as an application, will be a RMI server, and the servlet will be a RMI client, that for each doPost(), invokes a remote method, which, in the separated application, enters the task to the queue. This idea looks more logical to me, but as far as I know, RMI takes expensive performance, and maybe inter-process communication can be avoided at all.
If anyone has read all of this, and has an idea, or can give an advice, I will very appreciate it.
Thanks a lot!
Assaft

Answer 1

First of all I would like to thank all of you for giving excellent advices and paying attention.
I�ve read all of your replies, and think about the following:
There will be a servlet and a separated application (called �Events Manager� � �EM�), and they will communicate by RMI.
The servlet will recognize events entered by a user, (using XSL, it will traslate it to a known XML-based transfer object of the system, and invoke an insertEvent() method on the EM side. It will get a result, sometimes used for producing the response page.
The EM will have two threads:
1.     Listener for insertEvent() invocations � for each invocation, a singleton events factory will be used for constructing an event instance, which gets all the data given about the event from the servlet. The instances will be instantiated using dynamic loading of it�s class using the recognized event name. This instance will be written (using serialization) to a column in a database table, designed for events. The column of the execution time will sort this table.
2.     Executer for events � wakes up each 2 seconds, and gets the first row from the events table. Than, regenerates the instance (again, by serialization), and execute the doEvent() method of the instance (this method was declared in the Event interface, which every event implements). The result of the method will give an answer whether the event was totally finished, and its line can be removed from the table, or maybe it wants to be executed again in x seconds, so the instance must be stored again in the event�s row, and the table needs to be resorted. In this way I will have stateless events and statefull events.
In the queue there will be an event, regular as every other possible event, that backups the database to another storage. This event will have execution time of every 2 hours. This will guarantee that the whole system is backed up, and can be restarted without a problem.
In addition to that, this implementation will allow scalability of events, because in order to add new events to the system, the only things to do are to add the ability to the servlet side, and supply a class with the corresponding name, which implements the Event interface, and will be loaded and instantiated later by the first thread of the EM.
Last remark: I don�t use EJBs because I didn�t study it yet, and have only 3 weeks to finish the whole thing. In the future I�ll redesign it using EJBs.
Thanks a lot!
Assaf