OK, the option 2 looks good. That means we need to have an interface to query the status of the service. It could also be helpful if the service need a long time for running.
So B said:" Oh, yeah, I have got your request but can not repose currently. I need more time and you can query the status later through the /api/status" and when we query the status, B will say:"OK, I'm fine to finish the work" or "No, I can not finish the work" if the answer is OK, we could close the saga normally and if the answer is NO, we could do the compensate. NOTE, during the compensating, I think it might be also with this situation that the service need a long time for compensating and the asynchronous API could be also needed here. 2018-03-06 15:11 GMT+08:00 Eric Lee <eric.lee....@gmail.com>: > 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 <zh.f...@gmail.com>: > > > Can you describe the details when we doing the forward recovery currently > > please ? > > > > > > > > 2018-03-05 19:32 GMT+08:00 Eric Lee <eric.lee....@gmail.com>: > > > > > 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 > > > > > >
