camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ext2" <x...@tongtech.com>
Subject Re: about Camel Transaction
Date Sat, 24 Apr 2010 00:52:47 GMT
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 <xuhb@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



Mime
View raw message