The problem you are describing is pretty common and not specific to gRPC, it will be there for any micro service based architecture. Typically it will be the orchestration layer that will be responsible for making sure that both operations succeed, and implement any retry logic. Or have the order service does it’s job and then logs it, in case of failure, implement retry mechanism. Other way you could solve this problem is by implementing configuration for automatic retries in the service mesh (linkerd etc.)
On Mon, Nov 5, 2018 at 9:13 AM <[email protected]> wrote: > I find really hard to believe that Google uses XA transactions for its own > services. Take this AuditLog service > <https://github.com/googleapis/googleapis/blob/master/google/cloud/audit/audit_log.proto> > as an example which presumably is used/consumed as a middleware on their > services (due to service_name/method_name properties). Without taking into > account that probably the people in charge of an AuditLog API and Container > API are different teams which difficult the consensus on a one and only > *RPC based XA/2PC based system. > > Anyone from Google can shed some light on this matter? > > On Monday, November 5, 2018 at 2:48:50 PM UTC+1, Robert Engels wrote: >> >> You need a database and logger service that supports XA transactions. >> >> Sometimes it is easier to just log in the database under the same >> transaction. >> >> On Nov 5, 2018, at 3:16 AM, [email protected] wrote: >> >> Dead issue but I would like to resurrect it because this wasn't answered >> at all. >> >> Simple use case which can easily illustrate the problem: Two different >> services OrderService (with CreateOrder method) and AuditService (with >> Audit method). You want to create the order and, in case everything >> succeeded, log an audit entry. If you log an entry beforehand you could end >> with an audit log which never happened because the create order task >> failed. If you (try to) log an entry afterwards, the audit task could fail >> and end not logging something that happened which fails its sole purpose of >> having an audit log at all. >> >> What do you guys at Google do? >> * Compensate? >> * Nothing more than live with it? >> * In this concrete case having a custom audit log per service and the CDC >> (Change Data Capture) and replicate to the central service? >> >> @Jiri what did you end up doing? >> >> Thanks, >> >> >> On Wednesday, September 9, 2015 at 7:47:51 PM UTC+2, Jorge Canizales >> wrote: >>> >>> For Google's JSON/REST APIs we use ETag headers (optimistic concurrency) >>> to do these things. That's something easy to implement on top of gRPC, >>> using the request and response metadata to send the equivalent headers. >>> >>> On Wednesday, August 5, 2015 at 1:45:53 AM UTC-7, Jiri Jetmar wrote: >>>> >>>> Hi guys, >>>> >>>> we are (re-) designing a new RPC-based approach for our backoffice >>>> services and we are considering the usage of gRPC. Currently we are using a >>>> REST method to call our services, but we realize with time to design a nice >>>> REST API is a really hard job and when we look to our internal APIs it >>>> looks more RPC then REST. Therefore the shift to pure RPC is valid >>>> alternative. I;m not talking here about public APIs - they will continue to >>>> be REST-based.. >>>> >>>> Now, when there are a number of microservices that are/can be >>>> distributed one has to compensate issues during commands (write >>>> interactions, aka HTTP POST, PUT, DELETE). Currently we are using the TCC >>>> (try-confirm-cancel) pattern. >>>> >>>> I'm curious how you guys at Google are solving it ? How you are solving >>>> the issue with distributed transaction on top of the RPC services ? Are you >>>> doing to solve it on a more technical level (e.g. a kind of transactional >>>> monitor), or are you considering it more on a functional/application level >>>> where the calling client has to compensate failed commands to a service ? >>>> >>>> Are the any plans to propose something for gRPC.io ? >>>> >>>> Thank you. >>>> >>>> Cheers, >>>> Jiri >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "grpc.io" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/grpc-io. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/grpc-io/c727145c-b8a8-44f3-b857-416b4491362b%40googlegroups.com >> <https://groups.google.com/d/msgid/grpc-io/c727145c-b8a8-44f3-b857-416b4491362b%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> >> -- > You received this message because you are subscribed to the Google Groups " > grpc.io" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/grpc-io. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/0b814997-9c7c-41dd-a640-d24589ddc86b%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/0b814997-9c7c-41dd-a640-d24589ddc86b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- *Sankate Sharma* Principal Engineer 350 Convention Way, Suite 200 Redwood City, CA 94063 M. 408.910.1479 Payments API for Platform Businesses -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CANX-QRyLAd4jUMYjPs8JMteVT233whfz5C93FnRQu1oyBPwP_g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
