You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by ext2 <xu...@tongtech.com> on 2010/04/23 13:02:20 UTC
about Camel Transaction
Hi:
Sorry to raise the question again.
Recently , I check the EJB specification and do some test with ejb's
container managed transaction-policy , also the spring-transaction
template(they both are same)
After checking and testing EJB, I think the camel's current transaction is
deficiency;
For example, EJB container transaction support such usage:
Assuming EJB A invoke B. A, B used separate transaction(both is require-new
policy);
1)If B failed then the B's transaction will rollback.
2) The caller A could choice to omit the B's exception and commit
transaction, or not to omit B's exception and rollback transaction;
But camel's transaction doesn't support such usage. This deficiency is
caused by the camel's transaction-policy implementation mixed with
error-handler.
So if the camel's transaction implementation will not to use error-handler,
the deficiency will be correct.
If this worth to do in camel?
Or there are some other reasons that camel 's transaction must use
error-handler?
Thanks any suggestion;
Re: about Camel Transaction
Posted by ext2 <xu...@tongtech.com>.
Thanks Cluas. Ibsen:
Any-way , this is just my confusing about camel's transaction; I
don't sure if this limit is a good or bad.
As camel support extension custom policy, it's wonderful extension,
I could easily write a new transaction-policy not to use error-handler, and
the try-catch could work with it in my application.
===========================
Thanks Cluas. Ibsen:
Because camel 2.3 hasn't been release from the camel site, I tried
the trunk source of camel (https://svn.apache.org/repos/asf/camel/trunk/) .
it works same as the camel 2.2 release. It also cannot catch the exception
for the simple sample;
After check source code of 2.3 and 2.2, I find the truly reason is
because spring-transaction-policy's implementation which use the error
handler.
Do you remember I have raise another question previously: the camel
2.2's try-catch doest nested remove error-handler ? Camel 2.3 does correct
this. But the transaction-policy will force the process nested in try-catch
re-pick the transaction-error-handler again.
That's the real reason I feels confused: if transaction-policy used
nested in try-catch, the catch will not works;
Claus Ibsen wrote:
>I told you that <policy> in Spring XML does not work as expected in
>2.2 or older. You need 2.3 for that.
On Sat, Apr 24, 2010 at 2:52 AM, ext2 <xu...@tongtech.com> wrote:
> Maybe I hasn't illustrated my usage clearly.
> My usage is two separate nested global transaction(jta), not just a single
> transaction.
> If only a single jta transaction, exception process and transaction could
> work well together. But if new nested jta transaction declared(using
> require-new), exception process will conflict with transaction ;
>
> For example:
> <from jms> //here jms start a jta
> <transacted/> //default required policy will join the jms started
> jta transaction
> <dotry>
> <policy ref="transaction-require-new>//db1,db2 require
> consistency
> <db1 save>
> <db2 save>
> </policy>
> <doCatch> //will never be executed
> ..logging..
> </doCatch>
> </doTry>
>
> And also you have said, moving policy before doTry. But if so,the process
> in catch clause will join the rollback-ed transaction
> Although in the simple case, rollback of catch clause has no effect, but
> anyway maybe sometimes we need do some transactional operation in catch
> clause.
>
> ----------------------------------------
> Claus Ibsen [claus.ibsen@gmail.com] wrote:
>>Hi
>
>>I have explain to you before that such a scenario is described in
>>chapter 9 in the Camel in Action book.
>>The source code is at a public and free site.
>
>>Also this use case is explained on the Camel wiki pages, which does
>>only rollback on B and let A commit
>>http://camel.apache.org/transactional-client.html
>
>>Also camel-spring has a shit load of unit tests for transactions and
>>there would also be one for this use case.
>
>
>
> On Fri, Apr 23, 2010 at 1:02 PM, ext2 <xu...@tongtech.com> wrote:
>>
>> Hi:
>>
>> Sorry to raise the question again.
>>
>> Recently , I check the EJB specification and do some test with ejb's
>> container managed transaction-policy , also the spring-transaction
>> template(they both are same)
>>
>> After checking and testing EJB, I think the camel's current transaction
is
>> deficiency;
>>
>> For example, EJB container transaction support such usage:
>> Assuming EJB A invoke B. A, B used separate transaction(both is
> require-new
>> policy);
>> 1)If B failed then the B's transaction will rollback.
>> 2) The caller A could choice to omit the B's exception and commit
>> transaction, or not to omit B's exception and rollback transaction;
>>
>> But camel's transaction doesn't support such usage. This deficiency is
>> caused by the camel's transaction-policy implementation mixed with
>> error-handler.
>>
>> So if the camel's transaction implementation will not to use
> error-handler,
>> the deficiency will be correct.
>> If this worth to do in camel?
>>
>> Or there are some other reasons that camel 's transaction must use
>> error-handler?
>>
>> Thanks any suggestion;
>>
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: about Camel Transaction
Posted by ext2 <xu...@tongtech.com>.
Thanks Cluas. Ibsen:
Because camel 2.3 hasn't been release from the camel site, I tried
the trunk source of camel (https://svn.apache.org/repos/asf/camel/trunk/) .
it works same as the camel 2.2 release. It also cannot catch the exception
for the simple sample;
After check source code of 2.3 and 2.2, I find the truly reason is
because spring-transaction-policy's implementation which use the error
handler.
Do you remember I have raise another question previously: the camel
2.2's try-catch doest nested remove error-handler ? Camel 2.3 does correct
this. But the transaction-policy will force the process nested in try-catch
re-pick the transaction-error-handler again.
That's the real reason I feels confused: if transaction-policy used
nested in try-catch, the catch will not works;
Claus Ibsen wrote:
>I told you that <policy> in Spring XML does not work as expected in
>2.2 or older. You need 2.3 for that.
On Sat, Apr 24, 2010 at 2:52 AM, ext2 <xu...@tongtech.com> wrote:
> Maybe I hasn't illustrated my usage clearly.
> My usage is two separate nested global transaction(jta), not just a single
> transaction.
> If only a single jta transaction, exception process and transaction could
> work well together. But if new nested jta transaction declared(using
> require-new), exception process will conflict with transaction ;
>
> For example:
> <from jms> //here jms start a jta
> <transacted/> //default required policy will join the jms started
> jta transaction
> <dotry>
> <policy ref="transaction-require-new>//db1,db2 require
> consistency
> <db1 save>
> <db2 save>
> </policy>
> <doCatch> //will never be executed
> ..logging..
> </doCatch>
> </doTry>
>
> And also you have said, moving policy before doTry. But if so,the process
> in catch clause will join the rollback-ed transaction
> Although in the simple case, rollback of catch clause has no effect, but
> anyway maybe sometimes we need do some transactional operation in catch
> clause.
>
> ----------------------------------------
> Claus Ibsen [claus.ibsen@gmail.com] wrote:
>>Hi
>
>>I have explain to you before that such a scenario is described in
>>chapter 9 in the Camel in Action book.
>>The source code is at a public and free site.
>
>>Also this use case is explained on the Camel wiki pages, which does
>>only rollback on B and let A commit
>>http://camel.apache.org/transactional-client.html
>
>>Also camel-spring has a shit load of unit tests for transactions and
>>there would also be one for this use case.
>
>
>
> On Fri, Apr 23, 2010 at 1:02 PM, ext2 <xu...@tongtech.com> wrote:
>>
>> Hi:
>>
>> Sorry to raise the question again.
>>
>> Recently , I check the EJB specification and do some test with ejb's
>> container managed transaction-policy , also the spring-transaction
>> template(they both are same)
>>
>> After checking and testing EJB, I think the camel's current transaction
is
>> deficiency;
>>
>> For example, EJB container transaction support such usage:
>> Assuming EJB A invoke B. A, B used separate transaction(both is
> require-new
>> policy);
>> 1)If B failed then the B's transaction will rollback.
>> 2) The caller A could choice to omit the B's exception and commit
>> transaction, or not to omit B's exception and rollback transaction;
>>
>> But camel's transaction doesn't support such usage. This deficiency is
>> caused by the camel's transaction-policy implementation mixed with
>> error-handler.
>>
>> So if the camel's transaction implementation will not to use
> error-handler,
>> the deficiency will be correct.
>> If this worth to do in camel?
>>
>> Or there are some other reasons that camel 's transaction must use
>> error-handler?
>>
>> Thanks any suggestion;
>>
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: about Camel Transaction
Posted by Claus Ibsen <cl...@gmail.com>.
I told you that <policy> in Spring XML does not work as expected in
2.2 or older. You need 2.3 for that.
On Sat, Apr 24, 2010 at 2:52 AM, ext2 <xu...@tongtech.com> wrote:
> Maybe I hasn't illustrated my usage clearly.
> My usage is two separate nested global transaction(jta), not just a single
> transaction.
> If only a single jta transaction, exception process and transaction could
> work well together. But if new nested jta transaction declared(using
> require-new), exception process will conflict with transaction ;
>
> For example:
> <from jms> //here jms start a jta
> <transacted/> //default required policy will join the jms started
> jta transaction
> <dotry>
> <policy ref="transaction-require-new>//db1,db2 require
> consistency
> <db1 save>
> <db2 save>
> </policy>
> <doCatch> //will never be executed
> ..logging..
> </doCatch>
> </doTry>
>
> And also you have said, moving policy before doTry. But if so,the process
> in catch clause will join the rollback-ed transaction
> Although in the simple case, rollback of catch clause has no effect, but
> anyway maybe sometimes we need do some transactional operation in catch
> clause.
>
> ----------------------------------------
> Claus Ibsen [claus.ibsen@gmail.com] wrote:
>>Hi
>
>>I have explain to you before that such a scenario is described in
>>chapter 9 in the Camel in Action book.
>>The source code is at a public and free site.
>
>>Also this use case is explained on the Camel wiki pages, which does
>>only rollback on B and let A commit
>>http://camel.apache.org/transactional-client.html
>
>>Also camel-spring has a shit load of unit tests for transactions and
>>there would also be one for this use case.
>
>
>
> On Fri, Apr 23, 2010 at 1:02 PM, ext2 <xu...@tongtech.com> wrote:
>>
>> Hi:
>>
>> Sorry to raise the question again.
>>
>> Recently , I check the EJB specification and do some test with ejb's
>> container managed transaction-policy , also the spring-transaction
>> template(they both are same)
>>
>> After checking and testing EJB, I think the camel's current transaction is
>> deficiency;
>>
>> For example, EJB container transaction support such usage:
>> Assuming EJB A invoke B. A, B used separate transaction(both is
> require-new
>> policy);
>> 1)If B failed then the B's transaction will rollback.
>> 2) The caller A could choice to omit the B's exception and commit
>> transaction, or not to omit B's exception and rollback transaction;
>>
>> But camel's transaction doesn't support such usage. This deficiency is
>> caused by the camel's transaction-policy implementation mixed with
>> error-handler.
>>
>> So if the camel's transaction implementation will not to use
> error-handler,
>> the deficiency will be correct.
>> If this worth to do in camel?
>>
>> Or there are some other reasons that camel 's transaction must use
>> error-handler?
>>
>> Thanks any suggestion;
>>
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: about Camel Transaction
Posted by ext2 <xu...@tongtech.com>.
Maybe I hasn't illustrated my usage clearly.
My usage is two separate nested global transaction(jta), not just a single
transaction.
If only a single jta transaction, exception process and transaction could
work well together. But if new nested jta transaction declared(using
require-new), exception process will conflict with transaction ;
For example:
<from jms> //here jms start a jta
<transacted/> //default required policy will join the jms started
jta transaction
<dotry>
<policy ref="transaction-require-new>//db1,db2 require
consistency
<db1 save>
<db2 save>
</policy>
<doCatch> //will never be executed
..logging..
</doCatch>
</doTry>
And also you have said, moving policy before doTry. But if so,the process
in catch clause will join the rollback-ed transaction
Although in the simple case, rollback of catch clause has no effect, but
anyway maybe sometimes we need do some transactional operation in catch
clause.
----------------------------------------
Claus Ibsen [claus.ibsen@gmail.com] wrote:
>Hi
>I have explain to you before that such a scenario is described in
>chapter 9 in the Camel in Action book.
>The source code is at a public and free site.
>Also this use case is explained on the Camel wiki pages, which does
>only rollback on B and let A commit
>http://camel.apache.org/transactional-client.html
>Also camel-spring has a shit load of unit tests for transactions and
>there would also be one for this use case.
On Fri, Apr 23, 2010 at 1:02 PM, ext2 <xu...@tongtech.com> wrote:
>
> Hi:
>
> Sorry to raise the question again.
>
> Recently , I check the EJB specification and do some test with ejb's
> container managed transaction-policy , also the spring-transaction
> template(they both are same)
>
> After checking and testing EJB, I think the camel's current transaction is
> deficiency;
>
> For example, EJB container transaction support such usage:
> Assuming EJB A invoke B. A, B used separate transaction(both is
require-new
> policy);
> 1)If B failed then the B's transaction will rollback.
> 2) The caller A could choice to omit the B's exception and commit
> transaction, or not to omit B's exception and rollback transaction;
>
> But camel's transaction doesn't support such usage. This deficiency is
> caused by the camel's transaction-policy implementation mixed with
> error-handler.
>
> So if the camel's transaction implementation will not to use
error-handler,
> the deficiency will be correct.
> If this worth to do in camel?
>
> Or there are some other reasons that camel 's transaction must use
> error-handler?
>
> Thanks any suggestion;
>
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: about Camel Transaction
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I have explain to you before that such a scenario is described in
chapter 9 in the Camel in Action book.
The source code is at a public and free site.
Also this use case is explained on the Camel wiki pages, which does
only rollback on B and let A commit
http://camel.apache.org/transactional-client.html
Also camel-spring has a shit load of unit tests for transactions and
there would also be one for this use case.
On Fri, Apr 23, 2010 at 1:02 PM, ext2 <xu...@tongtech.com> wrote:
>
> Hi:
>
> Sorry to raise the question again.
>
> Recently , I check the EJB specification and do some test with ejb's
> container managed transaction-policy , also the spring-transaction
> template(they both are same)
>
> After checking and testing EJB, I think the camel's current transaction is
> deficiency;
>
> For example, EJB container transaction support such usage:
> Assuming EJB A invoke B. A, B used separate transaction(both is require-new
> policy);
> 1)If B failed then the B's transaction will rollback.
> 2) The caller A could choice to omit the B's exception and commit
> transaction, or not to omit B's exception and rollback transaction;
>
> But camel's transaction doesn't support such usage. This deficiency is
> caused by the camel's transaction-policy implementation mixed with
> error-handler.
>
> So if the camel's transaction implementation will not to use error-handler,
> the deficiency will be correct.
> If this worth to do in camel?
>
> Or there are some other reasons that camel 's transaction must use
> error-handler?
>
> Thanks any suggestion;
>
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus