>X-Originating-IP: [216.175.94.44] >Mime-Version: 1.0 >X-OriginalArrivalTime: 29 Sep 2000 17:15:11.0318 (UTC) FILETIME=[D3043F60:01C02A38] >Date: Fri, 29 Sep 2000 17:15:11 GMT >From: Nitin Sood <[EMAIL PROTECTED]> >Subject: JMS TemporaryDestinations and EJB 2.0 >Comments: To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] >To: [EMAIL PROTECTED] > >One of the goals of the newly released EJB 2.0 spec was to >"Define the integration of EJB with the Java Message Service." >However, the EJB 2.0 spec **doesnot** specify how EJB's will use >JMS TemporaryDestinations as described in the JMS spec section >4.4.3 >"One typical use for a TemporaryDestination is as the >JMSReplyTo destination for service requests." > >EJB's cannot use TemporaryDestination as decribed in the above case. > >For example consider the following scenario. A client >application(like a servlet) invokes create() on a >stateful bean. In ejbCreate the bean instance connects to a JMS >provider and a creates a TemporaryDestiantion and also >creates a MessageConsumer for the newly created >TemporaryDestination. > >The client then invokes a business method( called B1) on >the bean. This business method sends a JMS message to an administered >Destination, with JMSReplyTo set to the TemporaryDestination(as described in >the JMS spec section 4.4.3.) > >A JMSListner(a regular Java object and not a bean) picks the >the message and replies back to the TemporaryDestiantion. > >After some time, the client application invokes >another business method(called B2) on the stateful bean. >Business method B2 checks to see if any message has been >delivered on the temporary queue by calling MessageConsumer.receiveNoWait() > >The above scenario **doesnot** work if the stateful bean is >passivated between the two business method calls(B1 and B2). >For-example after B1, the container calls ejbPassivte. >Because the container serializes the bean instance, all con >nections(and thus the handle to the temporary destination) >to the JMS providor are lost. Now client calls B2. >Before invoking mothod B2, the container calls ejbActivate, >the beans gets a connection to the JMS provider, but cannot >get a handle back to the temporaryDestination as there is >not ceratinity that it gets back the original JMS connection >(TeomporaryDesitnation's lifetime is that of their connection and any of the >connection's sessions are allowed to create a MessageConsumer for them). > >So how does one use temporary destinations in EJBs ?? Am I missing >something. I would like to hear from the creators of the EJB and JMS specs. Nitin, The brief answer to your question is that not all concepts from JMS map into J2EE. JMS was originally designed as a client-side interface. Not all client-side concepts can be used in server-side components. In this case, JMS connection management should be left to the application server. It does not appear to be a good use of server-side resources to require a JMS connection to remain tied to a passivated stateful bean instance in order to preserve the JMS concept of temporary destinations. It was discovered early in the EJB 2.0 design that the JMS request/reply mechanism did not map well into EJBs that use container-managed transactions (CMT). Within a business method, the EJB programmer does not have any control of transactional boundaries. In JMS, a message sent within a transactional context is not actually delivered to its destination until the transaction is committed. Thus, you could not send a message and synchronously wait for a reply in one business method (without using bean-managed transactions). The message could not be sent until the method completed, but the method would never complete, since it would be synchronously waiting for a reply that would never come. We identified this case and documented that the JMS request/reply paradigm did not work well in this environment. (EJB 2.0 Spec, Section 16.3.5, "Use of JMS APIs in transactions.") The scenario you describe above works around these issues by placing the request in a separate method from the receipt of the reply. Additionally, the scenario avoids tying up valuable server resources by polling to see if the reply has been processed instead of synchronously waiting. However, the scenario requires polling the stateful session bean to see if the reply to the request has been received. It is envisioned that the majority of message processing will be performed by message-driven beans (MDBs). An MDB will asynchronously process messages as they are received, and no polling will be required. Additionally, the EJB 2.0 Spec allows concurrent consumption of messages received by an MDB. Since throughput within a server is important, it was important to design MDBs with the capability to concurrently process messages. You could adapt your scenario to use a non-temporary destination, and the reply-to field could be a destination that is serviced by an MDB that could notify the stateful bean instance that the reply had been received. -Joe Fialli, Sun Microsystems > >Thanks >Nitin Sood >_________________________________________________________________________ >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > >Share information about yourself, create your own public profile at >http://profiles.msn.com. > >=========================================================================== >To unsubscribe, send email to [EMAIL PROTECTED] and include in the body >of the message "signoff JMS-INTEREST". For general help, send email to >[EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
