Well, supposed we have such a simple scenario, A --> B If we apply forward recovery in this scenario, when sub-transaction B fails in the first time, it will return an error immediately to A. Hence, A can not be notified the results of B's retry operation and can not continue to process its later operations.
2018-03-06 14:21 GMT+08:00 Zheng Feng <[email protected]>: > Can you describe the details when we doing the forward recovery currently > please ? > > > > 2018-03-05 19:32 GMT+08:00 Eric Lee <[email protected]>: > > > Hi, all > > > > Currently, we encounter some problems in implementing forward recovery in > > saga. If we use synchronous API, the error code will respond immediately > if > > any exception throws. However, the transaction still goes on until it's > > done. It may lead to bad experience to the user as user may see view the > > wrong results. In Chris Richardson's talk: "Data Consistency in > > microservice using saga"[1], he provides two options as follows: > > > > > Option #1: Send response when saga completes: > > > > + Response specifies the outcome > > > > - Reduced availablity > > > > Option #2: Send response immediately after creating the > saga(recommended): > > > > + Improved availablity > > > > - Response does not specify the outcome. Client must poll or be > > > notified. > > > > And he prefers the #2 option to use asynchronous API. > > > > In my opinion, option #2 seems to be more user-friendly. Any other > > solutions for this or any comments for these two options are welcome. > > > > Reference: > > [1] https://www.infoq.com/presentations/saga-microservices > > > > --- > > Best Regards! > > Eric Lee > > >
