Andreas I would really like the transactions to be done at the level you are discussing. However, I'm also happy to stage that. In other words, lets do the low-level transaction handling first, make sure it works, see what users say, and then later burn it directly into the proxy/endpoints/sequences so that its more transparent.
Of course, if we think the code is really ready, we could jump straight to phase 2. However, its a big change to the core of Synapse, and also we would need a lot of documentation updates to make sure people understand the consequences. Paul On Tue, Nov 18, 2008 at 4:14 AM, Asankha C. Perera <[EMAIL PROTECTED]> wrote: > Hi Andreas > > 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? > > > Yes, in this case the request and response processed would be via two > threads. However, first of all: > > 1) We can only support this with a TM that allows a different thread to > resume a transaction > See JTA spec 3.2.3 "Note that some transaction manager implementations allow > a suspended transaction to > be resumed by a different thread. This feature is not required by JTA." > > 2) We can only do this in an environment that allows access to the > TransactionManager instance to invoke TransactionManager.suspend() and > TransactionManager.resume(). For example, JBoss will not expose > TransactionManager, out of its VM - [1],[2], so if we run standalone against > an already existing JBoss app server, we are in trouble > > Also, the advantage of letting the transaction flow through the calling > thread "naturally" has advantages. Many enterprise users already have client > libraries, that invoke on the resources, and EJB's on the JEE app servers. > By letting the transaction flow through, these client libraries linked up > via class/pojo mediators can also join the transaction (just by looking up > resources from the same app server) without any additional requirements. > > So my suggestion is to use the mediator implemented in SYNAPSE-480 to do the > suspend and resume, in supported environments only. Since the response > message context has access to the outgoing request message context sent out, > it could be injected with the same UserTransaction, which would then be > resumed by the transaction mediator. Does this sound reasonable considering > the above? > > asankha > > [1] http://www.jboss.com/?module=bb&op=viewtopic&t=35448 > [2] http://lists.jboss.org/pipermail/jboss-user/2007-March/046648.html > > -- > Asankha C. Perera > http://adroitlogic.org > > http://esbmagic.blogspot.com > -- 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]
