4

Can I start /spawn new java thread from within a MDB? I have a requirement to do some parallel processing from code in MDB and then return the control back to MDB.

Requirement: Message come to MDB , then some processing of code. Then two new slave thread are started which do some parallel work. Till then MDB is waiting. when threads finish the work. Then control is returned back to MDB, which completes the the related final/cleanup work.

Is it good idea to start a new thread ( Runnable) from MDB? If not then what should be the alternative?

mpromonet
  • 11,326
  • 43
  • 62
  • 91
James Cooper
  • 43
  • 1
  • 3
  • My question is: what would be the actual work that you want to do parallel (by the two slave threads)? Also, messages are processed parallel, are not they? – bpgergo Jun 07 '11 at 14:19
  • @bpgergo . I have a seperate third party processor class. I want to use that class in seperate threads. Just treat this main MDB as plain java class ,only a means to get message from JMS then later act as POJO. Does not a plan java application have needs to start multiple threads? – James Cooper Jun 07 '11 at 14:35

4 Answers4

2

It is a bad idea, if you are performing transactional work in the threads.

A thread that is currently performing work in a transaction started by the EJB container, is associated with a transaction context. In your case, the onMessage method in the MDB initiates a new transaction (unless you have specified a NotSupported descriptor), and the thread performing this transaction would be associated with a transaction context. Starting a new thread, does not propagate the transaction context to the child thread. This would result in a new transaction being created when the container detects that the child thread is attempting to access a transactional resource without a transaction context.

Although some (or most?) transaction managers support the presence of multiple threads possessing the same transaction context, this might (and most likely will) not apply to application initiated threads.

Vineet Reynolds
  • 76,006
  • 17
  • 150
  • 174
  • OP has not mentioned that the child threads will attempt to access transactional resource. – bpgergo Jun 07 '11 at 14:21
  • @Vineet Tks. I am not intending to use this MDB in transaction but spawn two thread but in the meantime let wait the MDB for threads to finish. – James Cooper Jun 07 '11 at 14:28
  • @bpgergo, that is usually immaterial. The EJB spec frowns on starting threads, but people do not know why. I've tried stating the most plausible explanation. – Vineet Reynolds Jun 07 '11 at 14:29
  • If not thread then there should be some alternative! Send control to some other MDB? But question is then how will the control return back to main MDB? – James Cooper Jun 07 '11 at 14:30
  • @Vineet Reynolds, I frown as well, but am also curious what OP wants to do in threads. – bpgergo Jun 07 '11 at 14:32
  • @James, if you are sure about what you are doing, then by all means go ahead and do so. I'd like to point out that reading a message from the queue/topic is a transactional activity, which commits only if the MDB processes the message successfully; the message is well and truly removed from the queue/topic only if the transaction commits. Any exceptions would have to be carefully handled. – Vineet Reynolds Jun 07 '11 at 14:35
1

Starting a thread from an MDB violates the specification.

Enterprise JavaBeansTM,Version 3.0, EJB Core Contracts and Requirements states in section 21.1.2 Programming Restrictions:

  • An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances.

  • The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.

Kaj
  • 10,862
  • 2
  • 33
  • 27
1

You are fundamentally missing the point of Java EE and MDBs.

A Java EE container is a managed runtime environment. The principle idea behind the Java EE container is that by delegating certain orthogonal concerns, such as transaction management, to the container, the component remains focused on business logic and (in utopia) be a reusable component that makes little assumption about its runtime environment.

Prior to MDBs, the Java EE container was a passive-reactive system that allowed no means for coordinating the action of a container side asynchronous active agents. Message Driven Beans then addressed this, providing a standard way for you to kick off an asynchronous action, server side.

You have an original event e0 which is consumed by MBD0. On message, MDB0 will generate e1 and queue a message in response to MBD1, which will then do its work and send msg to MDB2, etc.

There you have a simple workflow of n sequential steps using pub/sub messaging semantics (and o/c with asynchronous semantics), and all threads involved are managed by the container. If you wish to have concurrent actors working and then collecting results and kicking off a final action, consider using patterns involving JMS topics.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
alphazero
  • 27,094
  • 3
  • 30
  • 26
  • Tks. Yes, I want to collect the the info from all threads at the end in the main MDB. Even as you mentioned, if instead of threads I start a pool of new MDB's . Then how will the main MDB wait for final collected result? Can you elaborate your words "consider using patterns involving JMS topics"...how to implement this pattern? – James Cooper Jun 07 '11 at 15:42
  • The topic is the job, and entries are by steps. Your final bean will get notified until it gets the last step's message saying "here is the job status and results go fetch". – alphazero Jun 18 '11 at 01:00
1

Starting new threads with in MDB is bad practice. It will work but the new threads are not in control of application container so can behave unpredictably. They can even mess-up the thread management which container is trying to maintain. Worst affect is if the application is deployed in cluster then user defined threads will fail miserably.

In your scenario : Instead of starting new threads , create new MDB with logic of thread ( This way it will be managed by contaner now) then send message to these new MDB. If you want the control back to parent MDB then, I think , use your parent MDB in global transactional so that parent MDB will wait for child MDB to finish and control will return back.

supernova
  • 3,111
  • 4
  • 33
  • 30