2

I want to create a ThreadPool for a series of database calls(serial). We want to save those milliseconds. So we don't want to waste time in executing the database queries in serial. I'm working on a server application which already have many parallel nodes. In one of those nodes there are a series of database calls. I want to introduce parallelism inside a node that already running in parallel with other nodes.

Is thread pool executor a good choice? I don't know how many queries I'll be running. It depends on the state of the request object. So I can't fix the queue size of the thread pool.

This is the example that I have found.

Is this efficient? Is there any other alternative? Any suggestions will be appreciated.

2 Answers2

4

Spawning your own threads in a Java EE environment is usually a bad idea. Sometimes it has to be done, but you shouldn't do it if there's an alternative. I'm not sure exactly what you're trying to do, and what version of Java EE you're on, but if it's 6, then maybe you could use an asynchronous EJB.

Mike Baranczak
  • 8,291
  • 8
  • 47
  • 71
  • We are on Java 6, Geronimo container. So our architecture promotes threading. when a request comes in , we create independent nodes out of the request and get it executed in parallel. Now my problem is one of the nodes needs to parallelized. I understand Async EJB or messaging could be a solution. But is there a way we can stick to threading itself? – Vanchinathan Chandrasekaran May 08 '11 at 16:19
  • When you're using an async EJB (or JMS), you're still using threads, it's just that the container is managing the threads for you. If you try to spawn and manage the threads yourself, I guarantee that you'll run into problems. See here for further explanation: http://stackoverflow.com/questions/533783/why-spawning-threads-in-j2ee-container-is-discouraged – Mike Baranczak May 08 '11 at 16:30
  • 1
    re: Java version. I was talking about the version of Java EE, *not* the Java runtime. As far as I know, Geronimo only implements Java EE 5. – Mike Baranczak May 08 '11 at 16:33
  • How about If I use Geronimo Thread pool? http://geronimo.apache.org/apidocs/2.0.1/org/apache/geronimo/pool/ThreadPool.html – Vanchinathan Chandrasekaran May 08 '11 at 16:43
  • Maybe. I'm not familiar with the Geronimo APIs. – Mike Baranczak May 08 '11 at 17:03
  • 1
    Depending on the JEE technology used, some of them offer Application Scoped beans such as JSF and Seam. When using such technology, it is not a bad idea. Personally, I would try to leverage one of the following: Application Scoped beans, EJB3.1 @Asynchronous, JMS, or Quartz library which is widely used. – Mohamed Mansour May 29 '11 at 05:09
3

The standard solution for your problem is using JMS. Each query should be wrapped into command. Command should be sent as JMS message to queue. MDB (message driven bean) should receive them message and perform query asynchronously.

This approach has yet another advantage: if your are working with several physical servers the work will be distributed among them, so the system will be more robust.

AlexR
  • 114,158
  • 16
  • 130
  • 208
  • So threading with a threadpool executor a bad idea? What are the disadvantages of threading in this situation? – Vanchinathan Chandrasekaran May 08 '11 at 16:21
  • 2
    Thread pool executor is a great idea. But it is forbidden in JEE environment. You should let app. server to manage threads. I know only 2 "legal" ways to do this: JMS and JCA (that allows you to kindly ask app. server to get thread from its thread pool). But never manage your own threads in JEE environment! Obviously you can do this if you are implementing your own stand alone application. – AlexR May 08 '11 at 16:27
  • How about If I use Geronimo thread pool? http://geronimo.apache.org/apidocs/2.0.1/org/apache/geronimo/pool/ThreadPool.html – Vanchinathan Chandrasekaran May 08 '11 at 16:44
  • 1
    It probably OK, but it is the proprietary Geronimo's API. I think it is a bad practice to use proprietary APIs of container. I prefer the standard JEE solutions. – AlexR May 08 '11 at 16:53
  • I would also prefer to use something like JMS or EJB. It all depends on how much time we have to implement this. Thanks for your suggestions. – Vanchinathan Chandrasekaran May 08 '11 at 16:59