Re: [Discussion] Saga API design

[Eric Lee]

In Saga's current implementation, the process to mark saga end in abnormal
situation is as follows:

1. If all sub-transactions has corresponding compensated events, we mark
saga ended to this global transaction. If the ended event for abort started
event arrives later than saga ended event, for example:
SagaEndedEvent -> TxEndedEvent -> TxCompensatedEvent -> SagaEndedEvent. In
this situation, we have a periodly executor to delete duplicate saga ended
events and keep the last one.
2. The process is similar for forward recovery. If all aborted events has
corresponding ended events which are later than the aborted one, we mark
saga ended to this global transaction. If there are duplicate saga ended
events, we keep the last one.

2018-03-07 11:31 GMT+08:00 Willem Jiang :

> I prefer #2 option.
> As I think in our pack implementation, we just send saga_start and saga_end
> event in the normal Request and Response the happy path.
> But in the recovery model, it's a challenge that we don't know how to send
> the saga_end in the right time.
> It looks like we need to find a way to start and stop the saga explicitly.
> Any thoughts?
>
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
>   http://jnn.iteye.com  (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Mar 5, 2018 at 7:32 PM, Eric Lee  wrote:
>
> > 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
> >
>

Re: [Discussion] Saga API design

[Willem Jiang]

I prefer #2 option.
As I think in our pack implementation, we just send saga_start and saga_end
event in the normal Request and Response the happy path.
But in the recovery model, it's a challenge that we don't know how to send
the saga_end in the right time.
It looks like we need to find a way to start and stop the saga explicitly.
Any thoughts?



Willem Jiang

Blog: http://willemjiang.blogspot.com (English)
  http://jnn.iteye.com  (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Mar 5, 2018 at 7:32 PM, Eric Lee  wrote:

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

Re: [Discussion] Saga API design

[Zheng Feng]

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 :

> 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 :
>
> > Can you describe the details when we doing the forward recovery currently
> > please ?
> >
> >
> >
> > 2018-03-05 19:32 GMT+08:00 Eric Lee :
> >
> > > 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
> > >
> >
>

Re: [Discussion] Saga API design

[Eric Lee]

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 :

> Can you describe the details when we doing the forward recovery currently
> please ?
>
>
>
> 2018-03-05 19:32 GMT+08:00 Eric Lee :
>
> > 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
> >
>

Re: [Discussion] Saga API design

[Zheng Feng]

Can you describe the details when we doing the forward recovery currently
please ?



2018-03-05 19:32 GMT+08:00 Eric Lee :

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