CODEWITHSUNDEEP
jakarta-eejboss
webclimber
webclimber

Reputation: 2640

Writing on a separate thread for a web app

For one of the URLs that my clients will be calling, I want it to return as soon as possible with minimal disruption, so even if the database is down or slow, the request still returns pretty fast.

I still need to do some processing of the data sent, so I am thinking about having a separate "queue" that holds the data and then process in almost realtime but in a separate thread.

Before I go off and start writing this queue I wanted to ask if there are readily available classes/libraries to do this ?

This is a java web app, deployed with jboss.

Upvotes: 1

Views: 682

Answers (6)

Robin
Robin

Reputation: 24262

Actually, you can create the threads you want using commonj. It provides a light weight way of using threads and timers within the Java EE containers. More info here as well as this question has been raised many times.

This allows you to confirm to the restrictions of resource management within Java EE and avoid the more heavyweight solution of JMS (although it will work as well).

Upvotes: 1

kgiannakakis
kgiannakakis

Reputation: 104168

An alternative to JMS will be to persist the requests in a database and then process them altogether with a scheduler. You could use Quartz or Java EE timers for that.

Upvotes: 2

webclimber
webclimber

Reputation: 2640

The implementation ended up being a JMS message and a few Message Driven Beans processing the data wich has worked great and scaled pretty nice sofar.

I appreciate all the help and comments, specially the commonj, as well as the warnings about creating thread manually.

Upvotes: 0

Kaitsu
Kaitsu

Reputation: 4114

I've used Doug Lea's PooledExecutor with great success to handle this kind of things. There's also the ExecutorService nowadays directly in Java 5 and newer.

There were some comments that it is strongly discouraged to use your own threads in J2EE. Well, anytime you do threading yourself you have to be careful and this is no different really. I find the J2EE way of letting the server take care of everything a bit disturbing and don't like the way it is limiting the design choices you can take.

Just my 50 cents...

Upvotes: 0

Lars
Lars

Reputation: 509

Isn't this a perfect Scenario to rely on Ajax? Your long loading page is returned immediatly and contains an javascript ajax request to get your long processing request. While the request is pending, the user is faced with a spinner or other way to inform him, that the request might take some time. once it has returned, the response is inserted into your page via javascript.

Upvotes: 0

David Webb
David Webb

Reputation: 193686

Creating your own threads in a J2EE application is strongly discouraged and is outside the J2EE specification. I don't think you'll find a J2EE library to do what you want.

One of the main benefits of J2EE is that the server manages all your threads (and other resources) for you. If you start creating your own threads, the server doesn't know about them and can't look after them, so you're opening yourself up for potential resource leak problems amongst other headaches. To coin a phrase, you don't get a dog and bark yourself.

You'd be better off trying to create a solution that uses JMS. JMS is all about processing queues of messages so should be a good match to your requirements. Here's an article that talks about this a bit.

Upvotes: 9

Related Questions