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, glert...@gmail.com <javascript:> 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 grpc-io+u...@googlegroups.com <javascript:>. > To post to this group, send email to grp...@googlegroups.com <javascript:> > . > 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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. 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. For more options, visit https://groups.google.com/d/optout.
