The use of a cron job that does a WGET on a URL that triggers the background processing sounds nice, but what's the process that triggers that on a Windows box that doesn't have cron? A huge power of our application is that it's written in Java and we can run it easily on Windows or Linux or Solaris. Linux and Solaris could allow a cron job, but I'm not a Windows person so I don't know how I'd do the same there.
Also, if a process needs to be run every minute, or perhaps even every 5 to 15 seconds (like for processing a work queue), cron would be overkill because it would launch a new process, that process would have to construct the simple URL and the POST it to the system. Also, if someone else also did POSTs to that same URL, they'd also trigger the background processing though it wouldn't be "on schedule" per se. Using cron doesn't sound that much better than just writing a batch C/Java program that does this in a loop so that a process doesn't have to be started each time (though you then have the issue of what to do if the batch program terminates unexpectedly). The key for me is to have a very simple to deploy and manage application, and keeping Tomcat and a database running should be the minimum in our environment, though we probably will also have an Apache web server handling the SSL and static content like javascripts, images, URL rewriting, allowing for easy port 80/443 port listening without having to run as root, and allowing other types of backend apps run, like Perl/CGI or whatever. By far the easiest way to deal with work queues is to allow one thread to insert a transaction into a queue and then notify() the other waiting threads that work has been inserted. But that means that the "work queue thread" is a background thread and thus has issues with being truly compliant now and in the future. By far the easiest way to deal with background tasks is to simply launch a thread that waits() for a certain amount of time and then does work when that times out. Clearly, the cron type solution solves the thread issues, but at the expense of creating another program that needs to be configured and must run and must be checked if it's not running, and causes overhead each time it's launched. David --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
