Yes, it looks good to me. ------------------ Zhao Jun Apache Sharding-Sphere & ServiceComb
> On Jun 27, 2019, at 9:50 AM, Willem Jiang <[email protected]> wrote: > > We just leverage the message broker to make sure Alpha get the > transaction event from Omega. > In most cases Alpha don't need to talk back to Omega, we just need to > make sure all the transaction message are stored (Alpha can process it > later). > > If Omega cannot talk the message broker, Omega should abort the > transaction processing with transport exception. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Tue, Jun 25, 2019 at 8:42 AM Zhang Lei <[email protected]> wrote: >> >> Hi, Zhang jun >> >>> I just cared about the recovery scan thread design. >>> Kafka can ensure event message can be consumed by alpha exactly, but >>> recovery need know all the participated transaction response to decide >>> rollback or commit, so I think scan thread is also necessary. >> >> I am not sure, but I think Akka's persistence can solve this problem you >> care about. >> Of course, this ability needs to be verified >> >> Thanks, >> Zhang Lei >> >>> 在 2019年6月24日，上午10:46，赵俊 <[email protected]> 写道： >>> >>> Hi, Zhang Lei >>> >>>> A2 : I think we only need to ensure that the message can be reliably >>>> delivered to the state machine, The state machine is only a synchronous >>>> record state transition when the transaction is executed normally. At >>>> present, the compensation method based on table scan is also asynchronous. >>>> I am not sure if I have answered your question, or you can give me more >>>> information. >>> >>> If we have a mechanism that ensure main service can collect all the >>> participated transaction response from alpha correctly before >>> commit/rollback, it is OK. >>> >>>> Q2 : Also we should consider about recovery, it seems that recovery is as >>>> same as before based on database. >>>> A2 : I think the question you care about is how to recover when the alpha >>>> is down, this is a little different from the current version. >>>> 1. We can base on Kafka's reliability and control the offset of the topic, >>>> one message at a time >>>> 2. Of course, we can also do some extra design for it, such as logging the >>>> data log file locally after receiving the Kafka message. Resume the >>>> message by reading the data log file when the alpha machine restarts >>> >>> I just cared about the recovery scan thread design. >>> Kafka can ensure event message can be consumed by alpha exactly, but >>> recovery need know all the participated transaction response to decide >>> rollback or commit, so I think scan thread is also necessary. >>> >>> >>> >>>> On Jun 23, 2019, at 1:04 PM, Zhang Lei <[email protected]> wrote: >>>> >>>> Hi, Zhao Jun >>>> >>>> Thank you for your reply！ >>>> >>>> This design document does not elaborate on reliability aspects. >>>> >>>> My initial thought is this >>>> >>>> Q1 : It seems that omega should hold on after consuming the event message >>>> from Kafka instead of completing pushing message >>>> A2 : I think we only need to ensure that the message can be reliably >>>> delivered to the state machine, The state machine is only a synchronous >>>> record state transition when the transaction is executed normally. At >>>> present, the compensation method based on table scan is also asynchronous. >>>> I am not sure if I have answered your question, or you can give me more >>>> information. >>>> >>>> Q2 : Also we should consider about recovery, it seems that recovery is as >>>> same as before based on database. >>>> A2 : I think the question you care about is how to recover when the alpha >>>> is down, this is a little different from the current version. >>>> 1. We can base on Kafka's reliability and control the offset of the topic, >>>> one message at a time >>>> 2. Of course, we can also do some extra design for it, such as logging the >>>> data log file locally after receiving the Kafka message. Resume the >>>> message by reading the data log file when the alpha machine restarts >>>> >>>> >>>> Thanks, >>>> Lei Zhang >>>> >>>>> 在 2019年6月23日，上午7:08，zhaojun <[email protected]> 写道： >>>>> >>>>> I have some questions about the design. >>>>> 1. It seems that omega should hold on after consuming the event message >>>>> from Kafka instead of completing pushing message. >>>>> 2. Also we should consider about recovery, it seems that recovery is as >>>>> same as before based on database. >>>>> >>>>> ------------------ >>>>> Zhao Jun >>>>> Apache Sharding-Sphere & ServiceComb >>>>> >>>>>> On Jun 21, 2019, at 6:41 PM, Zhang Lei <[email protected]> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I have created the alpha-fsm module on branch SCB-1321 and submitted the >>>>>> design documentation, state machine prototype and test cases. >>>>>> If there is any problem, please let me know. >>>>>> >>>>>> Thanks, >>>>>> Lei Zhang >>>>>> >>>>>> [1] >>>>>> https://github.com/apache/servicecomb-pack/tree/SCB-1321/alpha/alpha-fsm >>>>>> <https://github.com/apache/servicecomb-pack/tree/SCB-1321/alpha/alpha-fsm> >>>>>> >>>>>>> 在 2019年6月20日，下午3:25，Zheng Feng <[email protected]> 写道： >>>>>>> >>>>>>> Yeah, I think Willem has create one [1] before and do you mind I assign >>>>>>> this issue to you ? >>>>>>> >>>>>>> [1] https://issues.apache.org/jira/browse/SCB-1258 >>>>>>> >>>>>>> Zhang Lei <[email protected]> 于2019年6月20日周四 下午2:34写道： >>>>>>> >>>>>>>> Hi, Zheng Feng >>>>>>>> >>>>>>>> Thanks for your advice, I will create a JIRA first and start with the >>>>>>>> design documentation. >>>>>>>> >>>>>>>> Lei Zhang >>>>>>>> >>>>>>>>> 在 2019年6月19日，下午8:09，Zheng Feng <[email protected]> 写道： >>>>>>>>> >>>>>>>>> Thanks a lot for sharing these information ! I think this state >>>>>>>>> machine >>>>>>>>> could be very experimental so it would helpful to create an >>>>>>>>> experimental >>>>>>>>> branch to add this module but not in the master branch. >>>>>>>>> >>>>>>>>> Zhang Lei <[email protected]> 于2019年6月19日周三 下午5:42写道： >>>>>>>>> >>>>>>>>>> I have completed some of the design and prototype in my github. >>>>>>>>>> >>>>>>>>>> In the design document [1] my original idea was that a transaction >>>>>>>>>> consisted of a SagaActor and several TxActors, and later TxAcotr was >>>>>>>>>> removed to reduce implementation complexity. >>>>>>>>>> I haven't had time to modify the documentation yet, but the SagaActor >>>>>>>>>> state machine [2] is up to date. >>>>>>>>>> Here you can see the test cases of SagaActor [3] >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> >>>>>>>> https://github.com/coolbeevip/playground/tree/master/state_machine_demo/saga-akkafsm >>>>>>>>>> < >>>>>>>>>> >>>>>>>> https://github.com/coolbeevip/playground/tree/master/state_machine_demo/saga-akkafsm >>>>>>>>>>> >>>>>>>>>> [2] >>>>>>>>>> >>>>>>>> https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/assets/saga_state_diagram.png >>>>>>>>>> < >>>>>>>>>> >>>>>>>> https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/assets/saga_state_diagram.png >>>>>>>>>>> >>>>>>>>>> [3] >>>>>>>>>> >>>>>>>> https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/src/test/java/coolbeevip/playgroud/statemachine/saga/SagaActorTest.java >>>>>>>>>> < >>>>>>>>>> >>>>>>>> https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/src/test/java/coolbeevip/playgroud/statemachine/saga/SagaActorTest.java >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Lei Zhang >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 在 2019年6月19日，下午2:34，zhaojun <[email protected]> 写道： >>>>>>>>>>> >>>>>>>>>>> If we use AKKA, how can we design the actors, and how can we >>>>>>>>>>> guarantee >>>>>>>>>> omega will receive the message synchronize. >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >>
