5

I have a web application that retrieves a (large) list of results from the database, then needs to pare down the list by looking at each result, and throwing out "invalid" ones. The parameters that make a result "invalid" are dynamic, and we cannot pass the work on to the database.

So, one idea is to create a thread pool and ExecutorService and check these results concurrently. But I keep seeing people saying "Oh, the spec prohibits spawning threads in a servlet" or "that's just a bad idea".

So, my question: what am I supposed to do? I'm in a servlet 2.5 container, so all the asynchrous goodies as part of the 3.0 spec are unavailable to me. Writing a separate service that I communicate with via JMS seems like overkill.

Looking for expert advice here.

Jason

Jason
  • 3,943
  • 12
  • 64
  • 104
  • Not quite a duplicate: http://stackoverflow.com/questions/3745905/what-is-recommended-way-for-spawning-threads-from-a-servlet-in-tomcat – Samuel Edwin Ward May 12 '14 at 19:58
  • Maybe you could create a cache, based on on hash of the parameters. This of course depends on how many possibilities you have, but that could help – Alexandre FILLATRE May 12 '14 at 20:00
  • is there a way you could pass your parameters into your database query? pulling data back that you throw away can't be good. – Nathan Hughes May 12 '14 at 20:07
  • Maybe, answering this question some of You will be able to answer also this question: http://stackoverflow.com/questions/23240497/async-servlet-preferred-implementation – pWoz May 12 '14 at 20:13
  • Look like background job to me. what are you doing with web ? are you feeding parameters through request ? are you displaying just results in web ? I missing the web role here. – Mani May 12 '14 at 20:29
  • Why do you think you need another thread? Servlets are already multi-threaded. – user207421 May 12 '14 at 22:11
  • Nathan: it's not possible to pass the parameters to a database query. We considered a stored procedure, but were concerned about portability if, god willing, we someday get away from Oracle. – Jason May 13 '14 at 10:47
  • Mani: I oversimplified for the sake of clarity. Technically, it's a graphical frontend app hitting multiple Spring-WS web services. The processing happens on the web service side. – Jason May 13 '14 at 10:48

5 Answers5

5

Nonsense.

The JEE spec has lots of "should nots" and "thou shant's". The Servlet spec, on the other hand, has none of that. The Servlet spec is much more wild west. It really doesn't dive in to the actual operational aspects like the JEE spec does.

I've yet to see a JEE container (either a pure servlet container ala Tomcat/Jetty, or full boat ala Glassfish/JBoss) that actually prevented me from firing off a thread on my own. WebSphere might, it's supposed to be rather notorious, but I've not used WebSphere.

If the concept of creating unruly, self-managed threads makes you itch, then the full JEE containers internally have a formal "WorkManager" that can be used to peel threads off of. They just all expose them in different ways. That's the more "by the book-ish" mechanism for getting a thread.

But, frankly, I wouldn't bother. You'll likely have more success using the Executors out of the standard class library. If you saturate your system with too many threads and everything gets out of hand, well, that's on you. Don't Do That(tm).

As to whether an async solution is even appropriate, I'll punt on that. It's not clear from your post whether it is or not. But your question was about threads and Servlets.

Just Do It. Be aware it "may not be portable", do it right (use an Executor), take responsibility for it, and the container won't be the wiser, nor care.

Will Hartung
  • 115,893
  • 19
  • 128
  • 203
2

Doesn't look like concurrency will help you much here. Unless it's very expensive to check each entry, making that check concurrent won't speed things up. Your bottleneck is passing the result set through the database connection, and you couldn't multithread that even if you weren't working on a servlet.

Idan Arye
  • 12,402
  • 5
  • 49
  • 68
2

There's nothing to stop you from hitting some ThreadPool from your Servlet, the challenge comes in getting the results. If the Servlet invocation is expecting some result from your submission of a Task to the TreadPool you will end up blocking waiting for the TreadPool stuff to finish so you can compose a response to the doGet/doPut invocation.

If, on the other hand, you devise your service such that a doPut, for example, submits a Task to a ThreadPool but gets back a "handle" or some other unique identifier of the Task returning that to the client, then the client can "poll" the handle through some doGet API to see if the task is done. When the task is done, the client can get the results.

Bob Kuhar
  • 10,838
  • 11
  • 62
  • 115
2

It's completely fine and appropriate. I have done countless work with Servlets that use thread pools on different containers without any problems whatsoever.

EJB containers (like JBoss) tend to warn against spawning threads, but this is because EJB guarantees that an instance of a Bean is only called by one thread, and some of the facilities rely on this and thus you could mess that up by using your own threads. In Servlet there is no such reliance and hence nothing you can mess up this way.

Even in EJB containers, you can use thread pools and be fine as long as you don't interact (like call) with EJB facilities from your own threads.

Enno Shioji
  • 26,542
  • 13
  • 70
  • 109
  • We aren't using EJB (thank god). We could run this whole mess on a cluster of Tomcat instances, but the customer has been seduced by Oracle salespeople. – Jason May 13 '14 at 10:50
1

The thing to watch out for with servlet/threads is that member variables of the servlet need to be thread safe.

Technically nothing stops you from using a thread pool in your servlet to do some post processing but you could shoot yourself in the foot if you create a static thread pool with say 20 threads and 50 clients access your servlet concurrently because 30 clients will be waiting (depending on how long your post-processing takes).

Kaveh Ghahremani
  • 119
  • 1
  • 6