5

We are creating a web app where we need to have concurrency for a few business cases. This application would be deployed in a tomcat container. I know that creating user defined threads in the web container is a bad idea and am trying to explore options that i have.

  1. Have my multi-threaded library used as a JCA component. We are averse to using this approach because of the learning curve that might be involved.
  2. I know that there's WorkManager API's available but i guess thats not implemented by tomcat so this option goes out.
  3. I did some research and found out that CommonJ library is recommended for Tomcat. Has anyone used it?
  4. Also, I see that there are ManagedExecutorService available but I am not sure how to use it and is it different from WorkManager API's (and the commonJ library)?

Any help on this appreciated. By the way, using JMS is out of question because of deployment environment. I am inclining towards points 3 and 4 but i do not have much knowledge on it. Could someone guide pls.

Improve this question

4 Answers 4

Reset to default
4

Since you're using Tomcat, don't worry about it and do whatever you want. The Servlet section of Java EE makes no mention of threads etc. That's mostly under the EJB section.

Tomcat itself doesn't do much at all in terms of worrying about managing threads, it's a pretty non-invasive container.

Its best to tie your threads to a ServletContextListener so that you can pay attention to the application lifecycle, and shutdown your stuff when you app shuts down, but beyond that, don't overly concern yourself about it and use whatever you're happy with.

Addenda -

The simple truth is Tomcat does not care, and it's not that sophisticated. Tomcat has a thread pool for each of the HTTP listeners and that's about the end of its level of management. Tomcat is not going to take threads from a quiet HTTP listener and dedicate them to a busy one, for example. If Tomcat was truly interested in how you create threads, it would prevent you from doing so -- and it doesn't.

That means that thread management outside of the HTTP context falls squarely on your shoulders as an implementor. Java EE exposes these kinds of facilities, and the interfaces make great reads. But the simple truth is that the theoretical capabilities espoused by the Java EE API docs, and the reality of modern implementations is far different, particularly on low end systems such as Tomcat.

Not to disparage Tomcat. Tomcat is a great piece of software. But for most of its use cases, the extra management capability simply is not necessary.

Setting up your own thread pool (using the JDK provided facilities) and working with your own thread lifecycle model will likely see you successfully through whatever project you're working on. It's really not a big deal.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

i am not sure that spawning threads is a good idea. if tomcat doesnt know about the threads then how would it control it? e.g. closing down the container would be a problem if the threads are running and also lets not forget that since the threads are outside the control of tomcat the threads will be competing with tomcat for memory.
Arya, Will is right, manage you own threads and (trust my pain) do not go the EJB/JCA route. The fact that you are in a Servlet container does not change the need to control your Thread pool. The Executor service can easily help you doing this. Tying the lifecycle of your Executors to that of your servlets guarantee clean initialization and shutdown.
BGR, will, do you guys have idea about ManagedExecutorService? would that be more appropriate in this context?
Not familiar with it. Looks like a ExecutorService with a listener. I can see uses, but it's not spectacularly interesting. The bigger question you need to address is ensuring that your threads can be stopped and managed at all, after that the Service does most of the work for you.
will, actually i am not sure if ManagedExecutorService is implemented by Tomcat or not but its surely is great thing to have. i think i can start the pool in a servlet context loader and ditto for shutting down the pool, but i really wanted to know if someone here has experience with ManagedExecutorService or CommonJ library
1

There are a couple of options. Regardless container restrictions that might or might not be in place, spawning individual threads on demand is nearly always a bad idea. It's not that this wouldn't work in a Servlet environment, but the number of threads you can potentially create might get completely out of hand.

The simplest solution to go with is a plain old Java SE thread pool via a normal executer service. Start the pool in a Servlet listener and provide access to it via some static variable. Not overly pretty, but it gets the job done. Depending on your exact use case this might actually be the best solution (if your use case is pretty low-level).

Another option is to add OpenEJB to your war, and then take advantage of the @Asynchronous annotation.

Yet another option, is to realize that one typically uses Tomcat if the business requirements are extremely simple or low-level. That's pretty much the entire point of using something as bare bone a Tomcat. As soon as you find yourself in need of adding (tons of) libraries, you might have outgrown Tomcat and might be better of using a server that already has the functionality you need (in this case asynchronous execution). Examples are TomEE, GlassFish, Resin, JBoss AS, Geronimo, etc.

Improve this answer

3 Comments

Arjan, actually out server would have heavy load on it. not too many concurrent users but a lot of users continiously talking to the server with some long running conversations (not necessarily transactional conversations). would you say that tomcat would be good enough for our requirement?
I used to work for Software-as-a-Service provider that used numerous Tomcat clusters to handle applications that handled tens of millions of page views per month per cluster. There is a misconception among a lot of people that Tomcat is just for small projects, but that's just not true.
Number of views is not what I meant with simple or small really. If the code is simple, in the sense that you don't need a UI, ORM, etc then basically your code is "low-level", and of course low-level code run millions of views (we had a part of our application running on Tomcat that could easily with two fingers in the nose do 6000 transactions/second/server, but all this thing did basically was accepting HTTP requests, putting stuff in some transfer queues and eventually persisting that in batches to the DB, couple of thousand LOC max)
0

Every Servlet -Java EE base component for HTTP request processing- in your Web Application is a Singleton, and each request runs in its own independent thread so there is no need to start/stop user generated threads on your own. Your Web Container -in this case Tomcat- manages all that stuff.

Besides that, you need to have in mind some considerations for multi-threaded processing in your code. For example, since Servlets are singletons and many threads are spawned for this class is a bad idea to have instance attributes in this components.

Improve this answer

1 Comment

carlos, actually my question is in totally different direction. What you are suggesting is the basic concept of http process and this i know. but there are situations where there are business processes invoked by the user which takes time and this is done through threads. the http request will just invoke the multi threaded process ... the rest of the process is going happen concurrently by threads...these threads right now are user defined threads which i am not comfortable with. any idea how could i remove usage these user defined threads.
0

I have used CommonJ many times and it works very well. It can be initialized and destroyed from a ServletContextListener.

Improve this answer

1 Comment

thanks for the reply christian, finally i get someone with experience in CommonJ. so my first question is that when i use commonJ, the threads that would be created, would that be in control of Tomcat? i hope its pretty scalable.... in your experience would you recommend it for moderately heavy load?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.