I added some notes to the JIRA 181, but it seems that the system lost them :( https://issues.apache.org/jira/browse/SYNAPSE-181
Basically I think we should not limit this to JMS. Let me give some examples. 1) If a user has a tx JMS queue and a tx connection to a database, then if there is a failure committing the transaction, both the queue and db updates should be rolled back 2) If a user uses commons transactions file system then changes made to the FS via that (not via the existing FS transport which is not transactional) should be added to the transaction and committed or rolled back 3) We could allow (optionally) for transactions to be in place even if the transport is not transactional. So if a request comes in on HTTP and there is a fault, we could rollback any database changes, and then send back an error code to the HTTP endpoint. This kind of behaviour needs configuration - in some cases the user wants the DB updates to be included. 4) We also need to support turning off transactions (or not enabling them) because of scenarios such as this: I use the new callout mediator with a JMS URL. The transaction is waiting for the callout to complete, but the callout message is not sent because the JMS queue is waiting for the transaction to complete. Finally, can I recommend we look at Atomikos http://www.atomikos.com/products.html#ate This seems a very effective, ASL licensed JTA implementation that supports transactions on incoming JMS work without requiring an EJB container or MDB. Which seems just what we need! Paul -- Paul Fremantle Co-Founder and VP of Technical Sales, WSO2 OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com
