On Nov 28, 2007 9:18 AM, Paul Fremantle <[EMAIL PROTECTED]> wrote: > 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
Paul when u said queue being rolled back, I assume you meant that the enqueue and deqeue operations are transactional and not the queue creation right? That is if I, withing the scope of a transaction, send messages to a qeueu and/or consume messages from a queue and if the transaction is rolled back, then I will dequeue the messages I published and/or enqueue the messages that I consumed. However if I create a queue within the scope of a transaction, do u expect the queue to be deleted if the transaction is rolled back? In AMQP/Qpid we don't do that and I think other JMS impls don't either (I stand to be corrected). > > 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! The XA implementation of any JMS provider should be able to support this outside of an EJB container. Paul, which of the following scenarios are you planning to support? 1) Lets say within the scope of a transaction, I push a message through the mediation engine that transforms the message and/or figures out the routing criteria and then is supposed to send to some other endpoint, but will wait till it receives a commit/rollback from the tx manger. If the transaction rolls back we drop the message and send a fault to the originator. If it's a commit we send the message through. In other words are we planning to make synapse an XA resource that can participate in a dtx transaction? 2) Or, are we thinking about relying on the transport to support dtx? 2.a ) In other words within the scope of a transaction I push a message to synapse via JMS (or another transport that has dtx support), but will sit in a queue until it gets commited at which point synapse will receive it. If it gets rollbacked then synapse wouldn't see it. 2.b) The other case is where synapse has got a message and it mediates the message and then sends it via JMS (or another transport that has dtx support). Then if a rollback happens the tx manager is going to deal with the transport XA resource directly and the message will be taken off the queue. It would be as if Synapse never sent it in the first place. For the option 2a we only need a dtx aware transport and zero changes for synapse. For option 2b we would need configuration changes for Synapse to let the transport know that certain out going messages from synapse should be done within a transaction and which tx manager to talk to etc.. Regards, Rajith > > 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 -- Regards, Rajith Attapattu Red Hat blog: http://rajith.2rlabs.com/
