Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Running multi-threaded java program from WebApplication  RSS feed

 
Anant Jagania
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Friends,

I have a multi-threaded java program which I have developed using java.util.concurrent.ThreadPoolExecutor (Lets say class A). There is one more class which implements the Runnable (Lets say class B). Class A checks for the records in the DataBase and if records found then it creates an object of Class B and assigns one row data of records to class B. After that the object of Class B is given to ThreadPoolExecutor and ThreadPoolExecutor executes the thread of class B. So there will be multiple objects of class B for each record of database.

Currently I am running this from shell script.

Now I would like to do the same thing using WebApplication.

Is it possible to Call Class A in a Web Application? If so, is it possible to monitor each thread created by Class A and and show the status of that thread? As well as end user can start/stop/resume/pause/suspend the thread from the GUI?

Would there be any problem running threads from a simple web application which some servlets and JSPs.?

Any input on this would be a great help. Thanks in advance.

Regards,
Anant
 
Chris Hurst
Ranch Hand
Posts: 443
3
C++ Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Generally creating threads in a web application is considered a bad idea as it should be your server (containers) job, unless your saying your effectively writing the server but that sounds like a bad idea as well
;-) as so many good ones exist. Thats not to say you can't do it or thats its not done, just its probably bad design as your limiting your servers ability to balance with other applications which is generally part of their design.

Get a good J2ee book and look at the mechanisms it gives, failing that the particulars of the J2EE server your intending to use i.e. does it expose its thread pools, have startup apps etc (they vary) assuming your using one and not effectively having your own HTTPserver with your threading code in which case do what you like ;-)
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't agree with the notion of not using threads in web apps. Using threads (or Tasks or Futures) one can start asynchronous operations without making the user wait for the response page.

In general, I'd say anything multi-threaded you can do in a desktop app, you can also do in a web app. It'll be easier to develop the code that monitors the status while it's still on the desktop though (no need to deploy code, restart the web app, etc.).
 
Anant Jagania
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the reply friends.

I was bit confuse by both replies. Because I dont know what to do. But now I have decided that I would create a Web App which will handle the threading.

I will have to go as per the requirement and thats why i have decided so.

Thanks Again.
Anant
 
Adam Schaible
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd argue that it's not a bad thing to spin up new threads in a web-container, too - lots of maintenance work is done by spinning up a new thread nightly (or some interval) - doing what needs to be done, then stopping.

This work is largely unrelated to users currently using the system. I can't really think of a reason to create a new thread for something the user is CURRENTLY doing if their activity is dependant upon the result of the created thread.

I don't see a big problem creating new threads, as long as it makes good sense.
 
Chris Hurst
Ranch Hand
Posts: 443
3
C++ Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'ed still argue that thread creation is intended to be via one of the J2EE mechanisms i.e the server is intended to manage threads ,

I would consult your J2EE containers documentation (I'm looking at some now and as a example contain stuff like "
WebSphere App Server strongly discourages you from creating threads
", obviously this depends of your container but here's another "Do not start threads in your Java server code, and keep threading transparent in your source files." says my Weblogic docs also., this kind of makes sense if you think about it and quite a lot of pluses when it comes to scalability, high availability etc though sometimes the over head of the J2EE constructs is OTT and hand rolled threading a winner for that reason . If you have a container that advocates rolling your own thread creation I'ed like to see it (and I'm not saying it doesn't exist just that I haven't seen one yet)

I'm NOT saying this is a rule that you shouldn't break just that its my belief that's how the architecture is intended to be used. In an ideal world your J2EE container will give you your multithreading for free, otherwise your just writing a server that runs on another server.

An an example with regard to your service maintenance thread ... wouldn't an ansynchronous bean do that (as an example of a possible solution) http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/welc6tech_asb.html

Slow server side action but you want interactive web pages .... AJAX to create an aysnchronous operation on the server ?? As an example, I'm not saying these solution are the best .. just that there are solutions, that multithread but leave the container in charge.


As a suggestion I would read your J2EE container documentation carefully and then if all else fails go for rolling your own threads.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!