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
