You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Andreas Veithen <an...@gmail.com> on 2008/11/16 16:53:47 UTC
JTA support in Synapse: general question
Hi devs,
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. 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). 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.
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.
Since these two approaches are incompatible which each other, what
will be the approach used in Synapse?
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: JTA support in Synapse: general question
Posted by Paul Fremantle <pz...@gmail.com>.
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 <as...@apache.org> 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
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: JTA support in Synapse: general question
Posted by "Asankha C. Perera" <as...@apache.org>.
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
Re: JTA support in Synapse: general question
Posted by Ruwan Linton <ru...@gmail.com>.
Well,
Irantha, it is required to support JTA standalone, but at the same time it
is much more important to support the application server translations as
well. Most of the time an ESB deployment is going to be on an existing
Application Server, though we would like people using ours standalone most
of the organizations tend to deploy it like this because of organizational
standards and many a reasons. That is what my experience about the
deployment of Synapse.
So I think we need to support both...
Thanks,
Ruwan
On Fri, Nov 21, 2008 at 12:24 PM, Irantha <ir...@wso2.com> wrote:
> On my view generally people like to have products that are easy to
> configure and use. Most of the time its easy to configure and get something
> working with a standalone product than with multiple products /clusters.
> When somebody has to setup another application server to get transactions
> working, there is more possibility that they will not try it at all or mess
> it up.
> I don't think most of the time people who are going to setup a ESB are
> doing it for the enjoyment of their leisure time. But I may be wrong.
>
> Thanks,
> Irantha
>
>
>
>
> Asankha C. Perera wrote:
>
>> Paul / Andreas
>>
>> I definitely like being able to provide standalone JTA support without a
>> JEE server - like we already support DataSources without a JEE server.
>>
>> Looking at real world JTA use, one would most definitely agree that JMS
>> and DB's are the most common, though there can and certainly will be other
>> resource managers. Typically a JMS provider (since we don't bundle one), a
>> DB, and requirement for JTA, and any other JTA aware RMs, makes me think
>> that the client already has a TM too :-) (e.g. a JEE server).. but I
>> agree this is just my personal view and I could be wrong in some cases.. So
>> I think we should not hard code anything specific to any of these standalone
>> TM's like Atomikos, JOTM etc.. or try to implement this support immediately,
>> as a pre-requisite to accept the enhancements we already have.
>>
>> We should rather be able to bind them (i.e. any standalone TM) to our
>> standalone JNDI, and use them as we use any other TM.. the research we need
>> here is how to do this.. and I'm sure that some users of these may have
>> already achieved this, or the providers of these already knows how to do
>> this, and would probably help us.
>>
>> asankha
>>
>> 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
>>> <an...@gmail.com> 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
>>>>
>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
Re: JTA support in Synapse: general question
Posted by Irantha <ir...@wso2.com>.
On my view generally people like to have products that are easy to
configure and use. Most of the time its easy to configure and get
something working with a standalone product than with multiple products
/clusters. When somebody has to setup another application server to get
transactions working, there is more possibility that they will not try
it at all or mess it up.
I don't think most of the time people who are going to setup a ESB are
doing it for the enjoyment of their leisure time. But I may be wrong.
Thanks,
Irantha
Asankha C. Perera wrote:
> Paul / Andreas
>
> I definitely like being able to provide standalone JTA support without
> a JEE server - like we already support DataSources without a JEE server.
>
> Looking at real world JTA use, one would most definitely agree that
> JMS and DB's are the most common, though there can and certainly will
> be other resource managers. Typically a JMS provider (since we don't
> bundle one), a DB, and requirement for JTA, and any other JTA aware
> RMs, makes me think that the client already has a TM too :-) (e.g.
> a JEE server).. but I agree this is just my personal view and I could
> be wrong in some cases.. So I think we should not hard code anything
> specific to any of these standalone TM's like Atomikos, JOTM etc.. or
> try to implement this support immediately, as a pre-requisite to
> accept the enhancements we already have.
>
> We should rather be able to bind them (i.e. any standalone TM) to our
> standalone JNDI, and use them as we use any other TM.. the research we
> need here is how to do this.. and I'm sure that some users of these
> may have already achieved this, or the providers of these already
> knows how to do this, and would probably help us.
>
> asankha
>
>> 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
>> <an...@gmail.com> 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
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: JTA support in Synapse: general question
Posted by Andreas Veithen <an...@gmail.com>.
I think we already have the required infrastructure to add a standalone
transaction manager without hardcoding anything into Synapse's core:
* We have a JNDI provider that we already use to expose data sources.
* We have an extension mechanism (startups) that can be used to configure
and initialize the transaction manager and to bind the UserTransaction and
TransactionManager resource to JNDI.
* We can use XAR to bundle everything together so that users only need to
drop the file in the right place and add the configuration to synapse.xml.
Andreas
On Fri, Nov 21, 2008 at 02:51, Asankha C. Perera <as...@apache.org> wrote:
> Paul / Andreas
>
> I definitely like being able to provide standalone JTA support without a
> JEE server - like we already support DataSources without a JEE server.
>
> Looking at real world JTA use, one would most definitely agree that JMS and
> DB's are the most common, though there can and certainly will be other
> resource managers. Typically a JMS provider (since we don't bundle one), a
> DB, and requirement for JTA, and any other JTA aware RMs, makes me think
> that the client already has a TM too :-) (e.g. a JEE server).. but I
> agree this is just my personal view and I could be wrong in some cases.. So
> I think we should not hard code anything specific to any of these standalone
> TM's like Atomikos, JOTM etc.. or try to implement this support immediately,
> as a pre-requisite to accept the enhancements we already have.
>
> We should rather be able to bind them (i.e. any standalone TM) to our
> standalone JNDI, and use them as we use any other TM.. the research we need
> here is how to do this.. and I'm sure that some users of these may have
> already achieved this, or the providers of these already knows how to do
> this, and would probably help us.
>
> asankha
>
> 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
>> <an...@gmail.com> 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
>>>
>>>
>> --
> Asankha C. Perera
> http://adroitlogic.org
>
> http://esbmagic.blogspot.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
Re: JTA support in Synapse: general question
Posted by "Asankha C. Perera" <as...@apache.org>.
Paul / Andreas
I definitely like being able to provide standalone JTA support without a
JEE server - like we already support DataSources without a JEE server.
Looking at real world JTA use, one would most definitely agree that JMS
and DB's are the most common, though there can and certainly will be
other resource managers. Typically a JMS provider (since we don't bundle
one), a DB, and requirement for JTA, and any other JTA aware RMs, makes
me think that the client already has a TM too :-) (e.g. a JEE
server).. but I agree this is just my personal view and I could be wrong
in some cases.. So I think we should not hard code anything specific to
any of these standalone TM's like Atomikos, JOTM etc.. or try to
implement this support immediately, as a pre-requisite to accept the
enhancements we already have.
We should rather be able to bind them (i.e. any standalone TM) to our
standalone JNDI, and use them as we use any other TM.. the research we
need here is how to do this.. and I'm sure that some users of these may
have already achieved this, or the providers of these already knows how
to do this, and would probably help us.
asankha
> 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
> <an...@gmail.com> 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
>>
--
Asankha C. Perera
http://adroitlogic.org
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: JTA support in Synapse: general question
Posted by Paul Fremantle <pz...@gmail.com>.
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
<an...@gmail.com> 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
> <sa...@opensource.lk> 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: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: JTA support in Synapse: general question
Posted by Andreas Veithen <an...@gmail.com>.
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
<sa...@opensource.lk> 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: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: JTA support in Synapse: general question
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: JTA support in Synapse: general question
Posted by Andreas Veithen <an...@gmail.com>.
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 <as...@apache.org> 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: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: JTA support in Synapse: general question
Posted by "Asankha C. Perera" <as...@apache.org>.
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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org