Fw: [smq3beta] MDB
There is a thread going on the swiftmq 3 beta mailing list about MDBs and SwiftMQ. While the resource-provider technique works for MDBs (my MDB gets the message), other folks wonder about transactions when using the technique described on the orionserver site. Does anyone know about XA transaction support in this case ? - Renaud - Original Message - From: Andreas Mueller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 27, 2001 8:28 AM Subject: [smq3beta] MDB That's great! It seems Orion doesn't need ASF to drive the MDBs. For the other question: The usual way to drive MDBs is to use the JMS provider's application server facilities (ASF) in conjunction with distributed transactions (XA). These things are specified in chapter 8 of the JMS spec. It is optional for a JMS provider to implement it. SwiftMQ doesn't implement it to avoid to the effort to support the different plug- in interfaces of the various container provider, because the contract between container and JMS provider is unspecified (the JMS spec describes only behaviors). There is also a transaction flow problematic which has to be addressed.
Auto-reply: Fw: [smq3beta] MDB
Please contact my manager Wendy Liau (650.506.8364) for any issues. Sam ---BeginMessage--- There is a thread going on the swiftmq 3 beta mailing list about MDBs and SwiftMQ. While the resource-provider technique works for MDBs (my MDB gets the message), other folks wonder about transactions when using the technique described on the orionserver site. Does anyone know about XA transaction support in this case ? - Renaud - Original Message - From: Andreas Mueller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 27, 2001 8:28 AM Subject: [smq3beta] MDB That's great! It seems Orion doesn't need ASF to drive the MDBs. For the other question: The usual way to drive MDBs is to use the JMS provider's application server facilities (ASF) in conjunction with distributed transactions (XA). These things are specified in chapter 8 of the JMS spec. It is optional for a JMS provider to implement it. SwiftMQ doesn't implement it to avoid to the effort to support the different plug- in interfaces of the various container provider, because the contract between container and JMS provider is unspecified (the JMS spec describes only behaviors). There is also a transaction flow problematic which has to be addressed. ---End Message---
