Multithreading using MDB

[sameerbkk]

have one multithreaded application which used to spawn different processes. This is application is being ported to J2EE environment.

Initially the plan was to use MDB (Message Driven Beans) to spawn mutliple threads and get the task done. But the main problem with MDB is the communication from the clients again.

When a message comes, the application server spawns one thread and calls the onMessage(). But the problem I am facing is to send notification from the client to the spawned thread. If another JMS message is send it will be delivered into another thread.

The threads will remain for some time because it is a long running process. Sometimes these processes should be aborted.

I don't know how to send notification to a thread (spawned for MDB) to abort the process. Please give me some inputs. Can I use transactions in this context?

Or is there a possible change in the container attributes that could help me achieve my goal.

Or is there a particular pattern that I need to adopt.


Many thanks,
Sameer

[ssmyka]

One possibility to communicate with the MDB Thread would be having a flag (in Database, static field, file ...). The Thread on each iteration would check this flag and interrupt itself if set to false.

Cheers,
Szymon Smyka

[halkw]

I think that it's concerned at the MDB in duplicate.
I recommend that you certain whether the Bean is Binded

For example, You can check whether the thread prosess is running or aborted as the sample code below

----------------------------------------------------------

...

if( cache.containKey(JNDIName) )
{
queueFactory=(QueueConnectionFactory)cache.get("JNDIName");
}
else
{
queueFactory=(QueueConnectionFactory)initialContext.lookup("JNDIName");
}

...

----------------------------------------------------------

plz refer to this docs

http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html

[halkw]

Sorry I maybe guess wrong; I understood it in error;

[jasperboy]

If it's a matter of sending a signal to terminate the MDB - why not get each single-threaded MDB to check periodically another app-wide queue filtered against a pre--agreed ID sent from the original client (normal JMS consumption as opposed to through the OnMessage() interface) to see if it should terminate early ?

That way your clients can simply send termination signals to one queue for a specific consumer.

[nick.hynes]

Initially the plan was to use MDB (Message Driven Beans) to spawn mutliple threads and get the task done.

IIRC the J2EE specification forbids you from spawning threads inside the J2EE container, so you need to be aware that your application may not port across different servers in a consistent way. For instance security permissions, contexts etc. may not be consistent across different vendors or server versions.

An alternative approach is to create a large pool of MDB, and make each JMS message a separate request. We considered this approach, but decided that it wouldn't meet our performance metrics.

P.S. If you do get an approach like this working, I'd be interested to know how it does perform and scale in practice... there is a lot of theory on this, but I haven't seen any hard data one way or the other.

[patrick_ibg]

This is such a basic server-side threading construct, the difficulty in implementing in EJB shows the immaturity of the standard (IMHO).

From what I understand, however, they might try to get asynchronous EJB3 calls in the next iteration (3.1) of the spec.

In the meantime, if you don't mind doing something JBoss-specific, you could look at asynchronous proxies:

http://docs.jboss.org/ejb3/app-server/tutorial/asynch/asynch.html

Another JBoss extension, Service POJOs, might also help do the trick:

http://docs.jboss.org/ejb3/app-server/tutorial/service/service.html

I think for what you are trying to do, you want a "worker" SFSB that implements the long-running job. It will keep state internally, but it exposes getter methods that allow clients to peek into the state. Then, you call it via another "facade" SFSB via an asynchronous proxy. At least this way you protect the end-client from calling JBoss specific code.