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 On Sun, Nov 16, 2008 at 18:13, Asankha C. Perera <[EMAIL PROTECTED]> wrote: > Andreas >> >> Now that work has started on JTA support inside Synapse and the >> transports, I have a general question. The model used in JTA is to >> bind the transaction to the current thread. With all the asynchronous >> and non blocking features we have in Synapse this is obviously not the >> most appropriate model. > > Not really.. even with the non-blocking http/s or any other transport, a > 'worker' thread that performs the mediation on a message will only be a > transport thread, or a Synapse thread (for tasks and/or iterate/split > mediators etc). This does not have any impact on the performance, as we can > only process messages bound by the limitations of the host system, as > configured via the thread pools. >> >> Instead, transactions should be bound to the >> MessageContext (either Axis2's or Synapse's one, TBD). Of course JTA >> transactions can be detached from one thread and resumed in another >> thread (assuming that a reference to the underlying TransactionManager >> is available). > > Well.. we actually do send the transaction along with the message, in a very > un-disruptive manner, so that elements aware of its presence (e.g. DB > mediators) could join the same transaction. The ability to detach a JTA > transaction is limited, and bound by the support/limitations of typical app > servers - for example, JBoss does not allow you to access the Transaction > manager from outside its app server JVM >> >> However that leaves us with two options: >> >> 1. Detach the transaction from the thread when it stops doing work >> related to the MessageContext and resume the transaction when a thread >> starts working on a MessageContext. >> > > Yes, I prefer to keep this 'optional' and triggered by the mediators > proposed to deal with these. In addition, we could consider a fault as a > criteria for a default rollback, like with JEE servers >> >> 2. When the transaction is started, immediately detach it from the >> thread and put it into the MessageContext. Whenever a mediator or >> transport needs the transaction, resume it and detach it again >> immediately afterwards. >> > > This does not give an advantage, or cause an overhead, since its just bound > typically via a thread local. Since people will only use transactional > services where they are needed, and explicitly requested, the most natural > thing is to let the transaction flow by default - and detach if required > *and* supported by the underlying implementations. > > asankha > > -- > Asankha C. Perera > http://adroitlogic.org > > http://esbmagic.blogspot.com > > > --------------------------------------------------------------------- > 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]
