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