Discussions

EJB design: multi-threading in J2EE

Bookmark and Share Get thread feed

  1. multi-threading in J2EE (6 messages)

    Hi,

    I have an application where client submits request to a JMS queue that is picked by a MDB, which carries out a very computational intensive process of forming a math-model and solving it using "operation research" (OR) algorithms.

    Now, I would like to decompose the problem solved by MDB into independent smaller problems. However, the results from each of the smaller problem is to be aggregated together so that for the client it is still a single problem being solved.

    What kind of approach can I use? Is there a way to achieve this using JMS & MDBs?

    Thanks for any suggestions!
    Reply to this

    Threaded Messages (6)

  2. multi-threading in J2EE[ Go to top ]

    Split your problem message to multiple smaller messages and publish in the queue.
    SPLIT BIGMSG(Q1) ---? SMALLMSG1,SMALLMSG2,SMALLMSG3--(Q2)
    SOLVE SMALLMSG->SMALLSOL1,SMALLSOL2,SMALLSOL3(Q3)
    AGRR SMALLSOL->BIGSOL

    You have to smartly code your MDB to handle all these scenarios other wise you can go for multiple beans listening different queues(Q1,Q2,Q3) for simplicity.
    Reply to this Reply to original

  3. multi-threading in J2EE[ Go to top ]

    I need to clarify certain points.

    - Number of SMALLMSGs from a BIGMSG is not fixed. So, first the BIGMSG will be processed and then on its outcome SMALLMSGs are determined.

    - There will be 1000s of different BIGMSGs that can be submitted to the initial queue.

    So, I understand that I should maintain a BIGMSG Queue, to which my MDB1 should be listening; this MDB will do the processing, determine SUBMSG(1)...SUBMSG(n) and write it to SUBMSG Queue. MDB2 will listen to this queue process the SUBMSGs in any order (SUBMSGs corresponding to different BIGMSG will exist in this queue) and write SOLMSG(1)...SOLMSG(n) to a SOLMSG Queue.

    If MDB3 is listening to SOLMSG Queue, how does it select SUBMSG(1)...SUBMSG(n)for a "particular" BIGMSG for aggregation purpose?

    Thanks for your reply!
    Reply to this Reply to original

  4. Aggregating results[ Go to top ]

    I think you understood the approach.
    Now the problem drills down to the aggregating smaller results. You can keep the nodeid in the solution message to aggregate the solutions.

    If the message you are using java objects/xml then coding stuff should not be difficult for you as you have coded those dunting OR stuff.
    Reply to this Reply to original

  5. use clues from weblogic integration...[ Go to top ]

    Weblogic integration if available allows you to solve this problem very easily with its custom controls. If you are not lucky enough to have this luxury, then you need to have some kind of co-relation id associated to each of the sub processes (problems) and make sure you aggregate at the end using these correlation ids. The problem to wary off however is the fact that one or more mdbs may fail to respond. How long will the consolidator wait to respond to the client???
    Reply to this Reply to original

  6. multi-threading in J2EE[ Go to top ]

    Can you decompose the problem in smaller tasks, which must sequentially? If yes, you can make a chain of MDB-s. Every MDB will be executing his own task (preferably using local session bean running in its own transaction) and on success will send results by JMS to the next MDB. However this approach has one problem. What if one of these small tasks cannot complete successfully? There is no way to reverse the changes done by previous MDB-s.
    If your tasks can run simultaneously, your “main” MDB can split send requests to a number of other MDB-s, which will do their smaller tasks. However, in this situation it’s hard to get the results of execution.
    Reply to this Reply to original

  7. multi-threading in J2EE[ Go to top ]

    You can have three MDB's that will solve the three smaller problems and then you can have one MDB that will send the messages to call the three MDB's.


    cheers
    Reply to this Reply to original