Andreas The lightweight transaction managers are definitely good. I personally like Atomikos, but I'm happy to consider any alternatives. Do you have experience with any?
Paul On Thu, Nov 20, 2008 at 10:15 PM, Andreas Veithen <[EMAIL PROTECTED]> wrote: > Sanjiva, > > The example was just meant to illustrate my point and probably there > are better examples. I just wanted to trigger a discussion about the > direction in which we are going. I agree with the approach outlined by > Paul and I think Asankha gave some very valuable information that we > need to take into account if we want to build higher level transaction > support later. > > My next question is what would be the recommendation to have > distributed transaction support (e.g. between JMS and a database) in a > Synapse stand-alone installation. Is there some lightweight Open > Source transaction manager that one can use (to avoid the burden of > installing a full-featured application server)? I'm thinking about > something as Jencks or JOTM. > > Andreas > > On Tue, Nov 18, 2008 at 09:29, Sanjiva Weerawarana > <[EMAIL PROTECTED]> wrote: >> Andreas Veithen wrote: >>> >>> Asankha, >>> >>> Let me explain my concern using an example. Imagine that the use case >>> is a JMS request-response proxy service and that the requirement is to >>> consume the request and to produce the response in a single >>> transaction (to guarantee that either there is a response or the >>> request remains on the queue). Also imagine that the target endpoint >>> uses HTTP. If the non blocking transport is used, then the request and >>> response processing will not happen in the same thread, right? This >>> means that at some point the transaction needs to be detached from the >>> thread processing the request and resumed in the thread processing the >>> response. Who is responsible for doing this and how would such a proxy >>> definition look like in Synapse? >> >> Andreas, given the transaction does not flow over the HTTP connection, >> what's the point of wrapping the HTTP request/response within a transaction? >> There's no way to abort the tx for example. >> >> In effect the HTTP interaction has to occur outside the tx right? At that >> point, what is the point of putting what happens after the HTTP response in >> the same TX as the original one because basically you've lost the semantic >> anyway. >> >> I'm prolly getting this wrong .. thanks for your patience in answering it! >> >> Sanjiva. >> -- >> Sanjiva Weerawarana, Ph.D. >> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ >> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ >> Member; Apache Software Foundation; http://www.apache.org/ >> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ >> >> Blog: http://sanjiva.weerawarana.org/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
