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/
