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 <willem.ji...@gmail.com>:
> 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 <eric.lee....@gmail.com> 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
> > 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", 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
> > + 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:
> >  https://www.infoq.com/presentations/saga-microservices
> > ---
> > Best Regards!
> > Eric Lee