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