I am a junior developer for a financial institution. Recently, I have been asked to create an add-on module to an exsisting web application. This module's purpose would be to check information in a database at regular intervals. The module would verify the information and verify if the information has expired (there is an expiry date field). If the information has expired, the module will flag these entries. My initial thought was to create a class that would implement Runnable. This way, it would be thread running and verifying the database at regular intervals. However, the senior developpers have informed me that this is not an option they would entertain. They have quoted that a thread's behaviour within a web container would be too unpredictable. My question is the following. Would anyone have an idea where I could locate information on this specific information. If threads are not a good solution, could someone let me know what would be an appropriate course of action. Any documentation or advice would be greatly appreciated. I do not want any code. What I am seeking is some guidance.
It's perfectly possible for user code to create threads in a web app, and it's actually a common occurrence. The java.util.Timer and TimerTask classes can be of great help in this regard, and would -IMO- be a better choice than Runnable.
I agree ... starting a small number of threads in a web container will not get you struck by lightning. But if you'd like to get outside the container and outside the JVM, trigger a standalone program from Quartz or Cron?
You can create your own threads the world won't end but its also bad form , J2EE apps share resources and thats a good thing i.e. in this case the web server should create \ pool threads consult your server documentation and you'll hopefully find a J2EE method supported already by your server ... e.g. timer service in J2EE 1.4
Nick, what platform (WebSphere, WebLogic, etc) are you running on? Websphere and WebLogic both provide a library for creating threads with the J2EE context. Google for CommonJ.
Ah, we're talking about at least two different things.
In an EJB container I'd be more likely to follow the spec re threads. Timer Service and vendor-specific workarounds are options in an EJB container. Asynchronous messaging to yourself is another. All that said, I have broken this rule in WebSphere for threads that ran only a few seconds.
The OP mentioned "web app" and J2EE which I read as a servlet container with no EJBs. I'd be more likely to play with my own threads in a servlet container and wrote one servlet that spins off a longer lived thread - several minutes - for a very rare user request.
Hi Stan, For the most part I agree with you and have also ran short-lived threads directly, however (for WebSphere at least) it is still considered bad practice to start your own threads from either the EJB or Web containers.
The easiest way to do this, and to avoid a conflict with your management, is to execute the behavior you want in a servlet, then reload the servlet every few minutes or so using either the container, or some Ajax\javascript thingo.
Your management team isn't going to be convinced because Stan, or Lasse, or Max from Javaranch said that what you want to do is ok. Heck, it'll probably get their heckle up.
Yes, it happens to be true, but that's beside the point.
They probably have a (sensible) policy in place that discourages junior programmers from threading in the Web Container: I can see that. Hell, I'd probably support it.
Show them you can swat flies by using a fly swatter and not a baseball bat, and you may find yourself presently surprised that they'll be more willing to listen to your ideas next time.
good luck, Max
Post by:autobot
Create symphonies in seed and soil. For this tiny ad:
a bit of art, as a gift, that will fit in a stocking