RPCs are not automatically retried currently, so there isn't a need to deduplicate. In the (likely near) future, we will provide a way to mark an RPC as idempotent, which will allow the library to retry. Note: if we can prove that the RPC never started (like a connection wasn't established), we will reconnect.
You can implement the concept of a transaction as a streaming RPC. Just make each message of the stream some action, and on completion you can commit the transaction on the remote side. That way if the RPC fails, the rest of the updates will not be applied. On Tuesday, November 8, 2016 at 1:57:37 PM UTC-8, Jojy Varghese (jojvargh) wrote: > > Hello Grpc group > We are considering gRPC for our messaging+rpc needs. Had a few questions > that would help us proceed: > > 1. How is idempotency handled? > 2. Is there de-duplication of requests on client side? > 3. How do we hook concept of transaction? > > > Thanks in advance, > Jojy G Varghese > > > > > > > > > -- 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/475144a2-3686-4d43-bcd4-481bffd1acd5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
