synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <pzf...@gmail.com>
Subject Re: notes on adding JTA
Date Thu, 06 Dec 2007 13:45:56 GMT
Thanks Rajith!

Paul

On Dec 4, 2007 6:28 PM, Rajith Attapattu <rajith77@gmail.com> 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 < pzfreo@gmail.com> 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
> > > > paul@wso2.com
> > > >
> > > > "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
> > paul@wso2.com
> >
> > "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
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

Mime
View raw message