Discussions

EJB design: Consolidated Session Bean Design/Pattern Questions

  1. Consolidated Session Bean Design/Pattern Questions (4 messages)

    Is there a well defined pattern/design for having a Session Bean perform multiple requests of other Session Beans and consolidate the results into the Session Bean that was contacted first.

    The multiple requests has to occur in parallel for performance reasones.

    So the question is, if I cannot create Threads to manage each of these parallel requests and poll within the life cycle of the Session Bean. How can I achieve this design/pattern with the specification of EJB Seesion Beans.

    I have considered Message Driven Beans, but I would still need a polling machanisme within the Session Bean to wait for all the results.

    My current implementation provides this functionality in an external JVM with a Thread Manager that is contactable via RMI.

    I would like to get rid of this component and get the service into the EJB container.

    Any help iis welcome.

    Thanks

    Pat

    Threaded Messages (4)

  2. response[ Go to top ]

    Pat,

    YOU can have threads in case if you have CONTROL over them. Why not? Even BEA recommends to use threads in cases when you actually need them and can fully control. Just do not include J2EE-related calls into your threads (such as executing EJB calls), and you're free to use them.

    Alex
  3. response[ Go to top ]

    Thus, can I call another EJB Session Bean within one of the Threads I have created?

    The bean will be stateless, so its the same stub has the parent Threrad.
  4. response[ Go to top ]

    Calling another EJB from within your threads is tricky and dangerous. Odds are very good that the security and transaction context will not propogate from your calling Session EJB to the other EJBs.

    In effect, your thread will be a generic client for your other EJB, and must use its own security credentials and initiates its own transaction.

    Of course, the same is also true of the MDB-based approach I suggested above ...
  5. Either (a) follow Alex's suggestion (which is fine) or (b) use Message Drive Beans (MDBs).

    1. Set up a queue to hold "operation-completion" messages.

    2. Have your Session Bean invoke your MDBs.

    3. Have your Session Bean act as a JMS client and monitor the "operation-completion" queue for results (this will block your Session Bean).

    4. Have your MDBs put the results of their work in the "operation-completion" queue when they finish.

    5. Once all the MDBs have put responses into the "operation-completion" queue, the Session Bean can unblock and send the complete set of responses to the client.