servicecomb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zhaojun <>
Subject Re: [saga-actuator]consider about adding StreamBasedSaga engine to integrate with shardingsphere
Date Mon, 29 Apr 2019 11:56:31 GMT
Hi, Willem

Saga actuator could not compatible with ShardingSphere currently,  there are 2 main problem
 1. If sql execute in saga transport instead of ShardingSphere, we can not see the result
of logic-sql even in one transaction, it is like this:
	update t_order set status=’start’ where usr_id=’tom’;      
        select status from t_order where usr_id=’tom’;                      —> we
can’t query ’start’ record as actuator haven’t executed.
        Insert into t_order values(?,?,?) ;
 2. If logic-sql execute in ShardingSphere, we cannot handle recovery before submit graph
result, as event log only wrote at saga engine.

so we should integrate saga-transaction like omega send event log step by step. 
It is better to make every instance do recovery Independently, instead of providing another
coordinator center service.
I feel that embed saga should have following  capability.
  1).It can provide service in jar package independent
  2).each embed saga only recovery their own transaction-data of this instance.
       If one instance crashed, we can introduce external service to do failover. 

so we consider about exending saga-acutator, if it can support submit task step by step in
one transaction, it is a good choice.
of course, there have many things we should do.

Zhao Jun
Apache Sharding-Sphere & ServiceComb

> On Apr 29, 2019, at 5:17 PM, Willem Jiang <> wrote:
> First Saga actuator need to build up the calling grapha before sending
> out the request.  I don't think you can do the step by step SQL
> invocation with Saga actuator.
> If you want to call the SQL execution step by step , you may need to
> switch to ServiceComb Pack project which has a coordinator to take
> care of the distributed transaction. But that introduce another
> endpoint(Alpha) to shardingsphere.
> From my understanding, Saga actuator is most efficient way to execute
> the SQL across different data nodes.
> Willem Jiang
> Twitter: willemjiang
> Weibo: 姜宁willem
> On Fri, Apr 26, 2019 at 6:41 PM zhaojun <> wrote:
>> Hi, all
>> currently, we have integrated with saga using graph based engine in shardingsphere[1]
>> it need us to collect all participated actual SQL, then submit to saga actuator in
commit/rollback phase.
>> if application crashed before invoking saga actuator, undo log of branch transaction
SQL will not be saved,
>> so recovery thread will not be executed correctly.
>> it's better that encapsulating every actual SQL as a saga task in shardingsphere
>> then submit to saga actuator realtime instead of batch processing all the SQLs at
commit/rollback phase.
>> this architecture will make the boundary more clear between shardingsphre and saga,
currently we have done some additional works for integrating saga.
>> any thought?
>> [1]:
>> ------------------
>> Zhao Jun
>> Apache Sharding-Sphere & ServiceComb

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message