Thanks Rajith! Paul
On Dec 4, 2007 6:28 PM, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > Paul, appologize for the delay in responding. I have swamped with some > last minute work and then have an exam next week. > Give me a few more days to get back to you. > > Rajith > > > On Nov 29, 2007 3:54 AM, Paul Fremantle < [EMAIL PROTECTED]> wrote: > > > 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. > > > > > > > I meant the messages not the creation or deletion of queues.Sorry I was > > unclear. > > > > 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). > > > > > > > No I don't believe other JMS providers do this either. > > > > 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. > > > > > > > That is true - any XA enabled JMS provider can be used in this way, but > > that does NOT mean that any JTA implementation provides this *without* an > > EJB container. > > The tricky part - and talking to people like David Jencks makes me > > believe this is actually tricky - is making sure the transaction is in place > > before the JMS onMessage() gets called. That is what the EJB container/MDB > > does for you. Now I asked David if the jencks project > > http://jencks.org/could do this. He indicated it might, but he also thought > > we might need to > > re-use some of the OpenEJB container code. However, reading the Atomikos > > documentation it seems like this does it "out of the box". > > > > I'm afraid I didn't really understand your options 1, 2a, 2b, so I'm > > going to try to clarify this. > > > > So firstly, lets be clear - the transaction is per *one-way* > > interaction. It's not a request/response full transaction that you would get > > with CORBA - its akin to the transactionality you get with MQSeries or > > another messaging engine. So in a request-response there will be two > > transactions - one for the request and one for the response. > > > > The second thing is that Synapse is not participating in any end-to-end > > application transactions. In other words, I'm not expecting to take an > > existing fully distributed XA transaction (for example a CORBA transaction) > > and add Synapse in the middle without breaking the existing 2pc > > transactionality. > > > > Lets just be clear about distributed 2PC. There is the model where the > > complete activity end-to-end is fully 2PC. This is implemented by CORBA and > > WS-AT. Then there is the model like JMS or MQSeries where the work is broken > > into transactional hops. Here is a classic example of this Queued > > Transaction Processing (QTP) model: > > > > transaction 1: > > System updates DB to say order sent, message queued. Both either happen > > or don't. > > > > transaction 2: > > Message dequeued and order logged in second database: both either happen > > or don't. > > > > The interesting case is the failure of the second transaction. In this > > case, the message dequeue (onMessage) will be tried again. Supposing it > > fails n times in a row, the usual behaviour is to put the failing message > > into an error queue and notify someone. In this case the originator needs to > > be notified by some process that their order was never accepted. > > > > Now in the case of Synapse, if we are dequeueing the message then its > > our responsibility to maintain the QTP transaction semantics. So now lets > > add synapse in the middle. > > > > trans 1 (as before) > > > > transaction 1a (synapse) > > Synapse dequeues the message, modifies it, updates a log database, and > > requeues it in a new queue (Q2). Either everything happens or not. > > If this all works, then transaction 2 can proceed as before (assuming > > that the tran2 JMS code has been pointed to the new queue (Q2)) > > > > If this fails, just as before, we now have to put this message into a > > dead message queue and notify the initial sender (out-of-band) that the > > message has not been accepted. > > > > Now in the more traditional 2PC model, there would only be one > > transaction - not two or three. However the problem with that is the > > distributed locking. > > > > Now Rajith you asked how we implement this. You are *almost* right in > > saying its the transports that need to implement this. So suppose we just > > discuss the JMS-->DBlogging->JMS mediation scenario. As long as we have a > > JTA transaction monitor in place, AND we have defined transactional queues > > and an XA database connection, AND we solve the issue of making sure the > > onMessage() happens within a new transaction, then we shouldn't have to > > write any extra code - the JTA transaction monitor will do everything else. > > However, there is still a lot of work making this happen. > > > > Also, we need to work through the scenarios when one side is not a > > transactional transport (e.g. HTTP) and follow those up. > > > > Paul > > > > No! > > > > > > > > > > > > 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/ > > > > > > > > > > -- > > 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/ > -- 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
