-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jacob,
Jacob Rhoden wrote: > Christopher Schultz wrote: >> You're better off not using Tomcat for this kind of thing. That's what >> cron and other system software packages are for. >> > I am curious, I find that moving the cron activities into the war file, > simplifies greatly the task of deployment and maintenance, why would you > not do it this way? Here are several reasons not to implement batch scheduling into your web application: 1. It is generally not part of the application, but part of the "system" that you are building. I like to keep components as simple and discrete as they can possibly be, instead of building one monster component. 2. While "every two weeks" was not clearly defined by the OP, I take it to mean actually every 14 days or so without interruption. In order to do that with a webapp, you'll need a lot of code to manage the schedule: the last time the event was triggered, how long before the next event, what happens if the server is down when the event should occur, etc. Otherwise, webapp reloads (which ought to be rare in production, but still...) will interfere with scheduling. 3. The webapp is limited to the permissions associated with the JVM. Unless you use Runtime.exec (which is arguably a mistake from a webapp), you are stuck running as "tomcat" or whatever user you run. 4. Following #3, you may have to alter your security manager's privileges if you want to do anything interesting. Perhaps this is not a big deal, but if you have to open-up your security manager, you might be compromising security in other parts of your application. 5. Your batch job runs at the same priority as the webapp. Yes, you can set the thread priority, but you can't "nice" the process or anything like that. 6. If there's a problem with your batch job, it could bring down your entire application. (Then again, that's what testing is for). Seriously, though. If your batch job starts to use more memory than you thought it would, your webapp users could start to feel the effects through sluggish server responses, etc. Here are several reasons to use cron instead: 1. Cron is already written, so you don't have to write a bunch of code to manage your schedule just to get batch processing to run. 2. The counter-arguments to everything above: you can "nice" a process, run it under any uid you want, it runs in its own separate memory space, etc. 3. When configured to do so, cron automatically emails you a report for your cron job, so you know what's up. The bottom line for me is that scheduled jobs like this are (usually) simply not part of the webapp, so they don't belong in there. No reasonable production web application is just a fire-and-forget WAR file deployment. A deployment process containing an upgrade to your cron job (which is probably unlikely to change across release anyway) should not be unmanageable for someone whose job it is to do deployments. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFw0fm9CaO5/Lv0PARAjXwAJ0TYsoP4SfAdgEfP4J7AAPMDYW2nACgtKxf rybxmprS5YtR2cmaA9Un8LU= =3oeA -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
