You might find this helpful: https://www.baeldung.com/transactions-across-microservices
> On Nov 5, 2018, at 11:20 AM, Robert Engels <reng...@earthlink.net> wrote: > > 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, glertxu...@gmail.com > <mailto:glertxu...@gmail.com> 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, glert...@gmail.com <> 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 <http://grpc.io/> ? >>> >>> Thank you. >>> >>> Cheers, >>> Jiri >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "grpc.io <http://grpc.io/>" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to grpc-io+u...@googlegroups.com <>. >>> To post to this group, send email to grp...@googlegroups.com <>. >>> Visit this group at https://groups.google.com/group/grpc-io >>> <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 >>> <https://groups.google.com/d/optout>. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "grpc.io <http://grpc.io/>" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to grpc-io+unsubscr...@googlegroups.com >> <mailto:grpc-io+unsubscr...@googlegroups.com>. >> To post to this group, send email to grpc-io@googlegroups.com >> <mailto:grpc-io@googlegroups.com>. >> Visit this group at https://groups.google.com/group/grpc-io >> <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 >> <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 > <mailto:grpc-io+unsubscr...@googlegroups.com>. > To post to this group, send email to grpc-io@googlegroups.com > <mailto:grpc-io@googlegroups.com>. > Visit this group at https://groups.google.com/group/grpc-io > <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 > > <https://groups.google.com/d/msgid/grpc-io/EE6D67F4-F769-4E3A-AC3D-B963B78BB402%40earthlink.net?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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/6F015A99-24F5-4179-BE28-D9FA9CE6A7DB%40earthlink.net. For more options, visit https://groups.google.com/d/optout.
