camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ext2" <>
Subject Re: about Camel Transaction
Date Mon, 26 Apr 2010 03:57:11 GMT
Thanks Cluas. Ibsen:

	Because camel 2.3 hasn't been release from the camel site, I tried
the trunk source of camel ( .
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

	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 <> 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 [] wrote:
>>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
>>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 <> 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
>> 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:
> Open Source Integration:
> Blog:
> Twitter:

Claus Ibsen
Apache Camel Committer

Author of Camel in Action:
Open Source Integration:

View raw message