synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: notes on adding JTA
Date Tue, 04 Dec 2007 18:28:10 GMT
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/

Mime
View raw message