If we want to manage the distributed transaction, we have to let the coordinate to know the subtransaction events, and the coordinate need to call the service agent to finish the transaction. It introduces some overhead comparing to the invoke the service directly. 

Take the below service invocations as an example,  the user start the invocation for the initial service, the initial service call the participate service and return response. initial service is the service who starts the distributed transaction,  the participate service just join the transaction with it's local transaction.  The below diagram just show the simplest way of service interaction. We just use it to demonstrate the overheads which distributed transaction manage system could introduce.Normally there could be more than one  participate service involved in the global transaction.



By using the pack, the Omega is started with the initial service and participate service. The Omega talks to the Alpha, and Alpha need to store the events into DB, These calls are remote invocations which mean coordinate system need to spend lot of time on the call.

 Here are the typical distributed service interaction with Saga, I just mark the invocations with red arrows, these invocation has request/response. It adds more than 8 remote invocation if we use coordinator to implement the Saga protocol.


Here are the typical distributed service interaction with TCC, I just mark the invocations with red arrows, these invocation has request/response.  It adds more than 8 remote invocation if we use coordinator to implement the TCC protocol.



  • No labels