Willem Jiang Twitter: willemjiang Weibo: 姜宁willem
On Mon, Apr 29, 2019 at 7:58 PM zhaojun <zhaoju...@126.com> wrote: > > 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(?,?,?) ; I think we can break the whole SQL interactions into smaller steps, and let saga-actuator do the job one by one. In this case, you can break the whole calling graph into several sub calling graphs. Any thought? > 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.ji...@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 <zhaoju...@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 > >> >
