Regardless of what google does or doesn’t do, you can’t solve the problem without XA transactions - either built in or rolling your own (lots of work and not very performant). The easiest way is to log everything in a persistent log that will occur, do the operations and verify that the expected operations were logged successfully - but that may even be possible as some operations cannot be rolled back - like log statements in a non transactional logging system. In this case a new log statement is created that logically supersedes the previous (same ID, etc)
It’s a pretty standard CS problem, but the work required can be relaxed if you don’t need full ACID across all resources. > On Nov 5, 2018, at 11:13 AM, [email protected] wrote: > > I find really hard to believe that Google uses XA transactions for its own > services. Take this AuditLog service 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. >>> 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. > 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/EE6D67F4-F769-4E3A-AC3D-B963B78BB402%40earthlink.net. For more options, visit https://groups.google.com/d/optout.
