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. >>>>>>> >>>>>>> >>>>> >>>>> >>> >>
