Attached is an answer from me directed to Jason. I never received a reply on it but it might be helpful for you to understand why SwiftMQ does not support ASF/XA. We will provide a JCA 2.0 RA (with XA) in future. Currently you can use the JMS bridge to connect to the app server's JMS impl (JBossMQ, WLS JMS or whatever). -- Andreas Mueller, IIT GmbH, Bremen/Germany, http://www.iit.de SwiftMQ - JMS Enterprise Messaging System, http://www.swiftmq.com -----Original Message----- From: "Andreas Mueller" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Wed, 25 Apr 2001 15:50:14 +0200 Subject: Fwd: Re: [JMS-INT] ASF Questions Hi Jason, FYI, attached is an answer from Joe Fialli from Sun regarding ASF questions. As you see, ASF is very much unspecified and the behavior is very much dependent on the app server. For example, the JMS RI dependents on 2 methods of a ServerSession from the J2EE RI to get the message acknowledgement working. JMS ASF will be deprecated in future and will be replaced by JCA 2.0 RAs, I guess. To provide a JCA 2.0 RA for SwiftMQ was our strategy, because it will be a standard way to integrate a JMS impl into an app server. That's the future. As I read your message in the developers list I thought it might be possible to give you a quick-and-dirty ASF to work with jBoss. But now I have to admit, that this will not be possible. There are several things which require to implement a complete new transaction context line into the router which is different from the current one. For example, normal JMS access is straight forward: connection->session->consumer. The session is the transaction context and the router's session object is connected with the client's session object. In ASF, the session of the router might be different from the session of the client because the ServerSessionPool is implemented by the app server. That's only one point which makes it very difficult to implement ASF to work with several app servers. The app server's JMS impls like jBossMQ have a bit easier job to do (like the JMS RI). They have only to respect their app server (like jBoss or the J2EE 1.3 RI) and if something will not work, they simply change things in the app server. This is very much different from SwiftMQ's situation as an independent JMS vendor. I'm very sorry but I have to accept the situation as is and this prevents us from implementing ASF and XA now. It's too much work for a feature which will be deprecated in future. I hope that you will keep in touch with SwiftMQ! -- Andreas Mueller, IIT GmbH, Bremen/Germany, http://www.iit.de SwiftMQ - JMS Enterprise Messaging System, http://www.swiftmq.com -----Original Message----- From: Joe Fialli - JavaSoft <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Wed, 25 Apr 2001 14:42:44 +0200 Subject: Re: [JMS-INT] ASF Questions Andreas, Sorry for not getting back to you sooner. Please use the [EMAIL PROTECTED] alias for this type of spec clarification if you wish quicker response time. If you forget the alias in the future, it is reachable from the jms website http://java.sun.com/products/jms/comments.html. I do monitor the jms-interest list, but not as closely as the spec questions alias. I rely on JMS vendors to answer as many quesionts as possible on that alias and I thank you for your previous responses on this alias. Please see answers below. >X-MDaemon-Deliver-To: [EMAIL PROTECTED] >X-Return-Path: [EMAIL PROTECTED] >X-MDRcpt-To: [EMAIL PROTECTED] >X-MDRemoteIP: 192.168.0.7 >Approved-By: Andreas Mueller <[EMAIL PROTECTED]> >Date: Sat, 21 Apr 2001 18:26:53 +0200 >From: Andreas Mueller <[EMAIL PROTECTED]> >Subject: [JMS-INT] ASF Questions >To: [EMAIL PROTECTED] > >Hi, > >I need some clarifications regarding the JMS application server >facilities and transaction contexts. > Please note that the description of these facilities in the JMS specification was optional and that the specification was published before the APIs were verified as sufficient. The JMS RI /J2EE RI integration loosely followed what was described in the application server support chapter in the JMS spec but not exactly. The J2EE 1.3 and EJB 2.0 specification are the only J2EE 1.3 specifications that were modified to integrate JMS into J2EE. J2EE 1.3 specifications describe the user experience of using messaging within J2EE 1.3 w/o formally describing the SPI between JMS and J2EE. So all answers to questions below are only intended to help you out by sharing our experiences. The integration of JMS into J2EE for J2EE 1.4 is being explored through Connector 2.0 effort. >The ConnectionConsumer consumes messages on the resp. connection and loads >a session, provided from a ServerSessionPool, with one or more messages >which are then consumed from the session's MessageListener. The >implementation of a ServerSessionPool is not specified in the JMS spec. >Thus, sessions might be pre-created, created on demand etc. Correct. >What I'm struggling with is the transaction context. In JMS this is always >the session. But what is the intention when using ASF? The EJB 2.0 specification describes the transaction context that messages are being delivered within. If the Message Driven Bean(MDB) is declared as a Container Managed Transaction context (CMT), each JMS message is delivered in an individual transactional context. Thus, if 3 messages are delivered concurrently to 3 MDB instances, each message is delivered to an individual transactional context that is triggered just BEFORE the message is delivered to the onMessage method. In the JMS RI/J2EE RI integration, we added beforeMessageDelivery and afterMessageDelivery callbacks to ServerSession interface. These methods were called by the JMS RI just before delivering a message. The ServerSession is implemented by the Application server, if the serversession determined it was being called for a CMT MDB, it would enlist the JMS session that the messages was being delivered to into a global transactional scope. (JMS RI implemented JTA and J2EE RI used these interfaces. J2EE 1.3 Specification does not require JTA support of JMS vendors, but it does require that all resources accessed in a transactional context participate in a distributed txn, by any means attainable by the application server.) JMS Messages delivered to bean managed transactional context MDB are delivered OUTSIDE of any transactional context. (Once again described in the Message Driven Bean chapter of EJB 2.0.) Thus, the application container is responsible for acknowledging receipt of its message AFTER the MDB's onMessage returns without throwing a runtime exception. I believe the J2EE RI simply used AUTO_ACKNOWLEDGE JMS sessions for BMT MDB case to satisify the EJB 2.0 requirement that the container ensure that messages delivered to BMT MDBs are acknowledged. In summary, messages delivered to concurrently consuming MDB instances DO NOT MAINTAIN the serial order of processing. There is no ordering relationship between messages consumed by a concurrent processing MDB. This difference is justified by the fact that server's require high throughput and client side JMS sacrificed high throughput for easy of programming ease. Each message delivered to a MDB is delivered to a potentially different session context and should be treated as being in a different context. Client Acknowledge mode does not have any application in MDBs. > The messages are >forwarded from the ConnectionConsumer to a random session from a pool. >What is the transaction context here? When the session is created on >demand, the message is fetched before the resp. session exists (it will be >created when the ConnectinConsumer requests it from the pool), thus the >transaction context might not exist when a message is fetched. > >Say, there are 2 session in that pool, A and B, pre-created and the >ConnectionCosumer delivers 4 messages to them, evenly distributed. So A >gets message 1+3 and B gets 2+4. The sessions are transacted. When A >commits after receiving message 3, are then only 1+3 committed or 1+2+3? Since session pooling is in place, messages 1 and 3 should be treated as being delivered in DIFFERENT transactional contexts. As each message is received it should be committed or rolled back. For CMT MDB, the mdb container manages which should be called. For BMT MDB, the container once again is incharge of acking or not. >When B makes a rollback after receiving message 4, are then 2+4 rolled >back or 2+3+4? There should be no relationships between any messages delivered to a MDB. I hope these explainations help. Since the application server interfaces are optional, there are no compatibility test standards for these interfaces. Only the MDB usage of these interfaces is being formally tested by the J2EE CTS. -Joe Fialli, Sun Microsystems, Java Enterprise Group > >TIA, >Andreas > >-- >Andreas Mueller, IIT GmbH, Bremen/Germany, http://www.iit.de >SwiftMQ - JMS Enterprise Messaging System, http://www.swiftmq.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". ------------------------------------------------------ SwiftMQ developers mailing list * http://www.swiftmq.com To unsubscribe from this list, send an eMail to [EMAIL PROTECTED] and write in the body of your message: UNSUBSCRIBE developers <your-email-address> Archive: http://www.mail-archive.com/developers@mail.iit.de/
