servicecomb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Lee <eric.lee....@gmail.com>
Subject Re: [Discussion] Saga API design
Date Tue, 06 Mar 2018 07:11:12 GMT
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.feng@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.ltk@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message