servicecomb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zhaojun <zhaoju...@126.com>
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
exist.
 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 <willem.jiang@gmail.com> 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 <zhaojunv3@126.com> 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
side,
>> 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]:https://github.com/sharding-sphere/shardingsphere-spi-impl/tree/master/sharding-transaction-spi-impl/sharding-transaction-base-spi-impl/sharding-transaction-base-saga
<https://github.com/sharding-sphere/shardingsphere-spi-impl/tree/master/sharding-transaction-spi-impl/sharding-transaction-base-spi-impl/sharding-transaction-base-saga>
>> 
>> 
>> 
>> ------------------
>> Zhao Jun
>> Apache Sharding-Sphere & ServiceComb
>> 


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