Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Using threads in J2EE application

 
Swamy Kumar
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A question regarding the use of threads in J2EE application. I do understand that J2EE doesnt subscribe to applications using their own threads. However, there are situations where in using a daemon thread would prove beneficial. For instance if we have a file that we would need to track for changes - we could have a thread (that is spawned from a web application) that monitors this file for change periodically. The benefit of this approach is that a file change can be made to re-parse the file thus avoiding unnecessary server re-starts.

The premise that J2EE uses against application using threads is that too many threads could interfere with the containers activities. I did use such a thread(as explained above) to periodically (twice a day) check for file changes - and didnt find any major issues.

Now, if we have a thread that periodically checks for changes - would there be any serious drawback ?
 
mc khan
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Spawning threads is prohibited in the EJB spec, though it is still an issue inside the web-container. We need to spawn a lot of threads in our web application and the only issue we encountered was with JAX-RPC Webservice client. If you have handlers or any declarative stuff defined in for WS client and the proxy is retrieved in a non-container managed thread then the configurations would not be applied to the WS client.

I don't see any issues in your case. Just make sure you manage your thread. Don't let is run away with the CPU :-). I don't think you need to think about clustering/fail-over for your thread.
 
Ranganathan Kaliyur Mannar
Bartender
Posts: 1103
10
Java Netbeans IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I believe this can be done with the EJB TimedObject. Though I haven't come across any implementations and neither have I done one.


Ranga.
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you were doing this in a full blown EE app, i.e. one using EJB, then you'd be better of using the timer service with a stateless session. That said you can't use the java.io package from an EJB so your data would have to be in a suitable EIS.

Accessing a file directly from your app has a bad smell about it, not least for portability issues, unless it's part of a legacy process over which you have no control. A better option would be to have whatever process changes the file simply send it as JMS message or document-oriented web service call, depending on your architecture.
 
Lann Lu
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't see any issue with your approach. It will be working fine definitely in any container.

The reason the container is against spawning thread is that it can not manage the spawned thread, since container ties transaction & security context with the current thread.

If you don't need transaction/security management from container, and the task you will perform is simple, by that, I mean simple, and isolated, then don't afraid of using thread.

Please see a JSR??? for "workmanager" (from IBM, BEA), I forgot the JSR number.

As well don't afraid to use IO package if you know exactly what you are doing. No need to resort to EIS or Timed Object.

Use simple design to solve simple thing.

Peace,
Tao
 
Swamy Kumar
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the responses.

Regarding the messaging option - it could work out if an application is the trigger, so that we could introduce an MDB in the recipient application. However, the trigger here is a manual file change.
 
Phil Haigh
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Swamy Kumar:
Thanks for the responses.

Regarding the messaging option - it could work out if an application is the trigger, so that we could introduce an MDB in the recipient application. However, the trigger here is a manual file change.


One solution to your problem would be to run a non-JEE (but possibly Java) daemon process (or on unix, a cron job) that watches for changes in your file and then pokes the JEE system to act on that change. This avoids the need to create and manage threads in you JEE application and is a neat and simple solution.

I disagree with Lann Lu's assertion that 'everything will be fine'. It would be very easy to tie the server in knots if you start playing with thread synchronisation, for example. And as you are working outside the EJB specification, what you get working on one application server may not work as predicted - or at all - on another one. Potentially brittle code and it has a bad smell to it.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic