synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <>
Subject Re: JTA support in Synapse: general question
Date Tue, 18 Nov 2008 04:14:54 GMT
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 

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 C. Perera

View raw message