The user group for an RPC framework is not the right place to ask how you should implement your transactions. This is 100% orthogonal issue, and one that you would have with REST services too.
On Mon, Nov 5, 2018 at 6:13 PM <[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. > -- Christian Rivasseau Co-founder and CTO @ Lefty <http://www.lefty.io> +33 6 67 35 26 74 -- 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/CAJ6g4%3DZOk_znQVbpzB84r0nT7Gj39NbYotX_34X1u9bkYN0c1w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
