Uploaded image for project: 'Couchbase Documentation'
  1. Couchbase Documentation
  2. DOC-5928

More details and how to samples for ambiguous result handling

    XMLWordPrintable

Details

    Description

      Ambiguous result handling should be more prescriptive with how-to code samples in the following page:

      https://docs.couchbase.com/server/6.5/learn/data/durability.html

      The above page has general guidelines but it will be good to include sample code for handling various paths when an ambiguous result is received.

      Daniel Owen FYI.

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          owend Daniel Owen added a comment -

          Hi Tony Hillman,

          I've been talk to Daniel Roberts about what is required here and is working on some code samples to help.
          The main concern is regarding non-idempotent durable writes.
          In particular - we current state in the documentation

           If the attempted durable write is not idempotent, the options are:
          Verify the current state of the saved data; and re-attempt the durable write if appropriate.
          Return an error to the user.
          

          I thing we need code samples showing how to cope with am ambiguous result. And the gotchas associated with trying to use non-idempotent durable writes a perform tasks such as incrementing a value.

          Daniel Roberts. Can you detail some of the challenges we discussed in this ticket? - thanks

          owend Daniel Owen added a comment - Hi Tony Hillman , I've been talk to Daniel Roberts about what is required here and is working on some code samples to help. The main concern is regarding non-idempotent durable writes. In particular - we current state in the documentation If the attempted durable write is not idempotent, the options are: Verify the current state of the saved data; and re-attempt the durable write if appropriate. Return an error to the user. I thing we need code samples showing how to cope with am ambiguous result. And the gotchas associated with trying to use non-idempotent durable writes a perform tasks such as incrementing a value. Daniel Roberts . Can you detail some of the challenges we discussed in this ticket? - thanks

          As is the issue with an ambiguous response, finding out whether we've updated the value or not is in some way unknowable. In the case of a single client, we can use CAS values to determine whether or not the value has been modified by the ambiguous operation (but not if it may still be in the future - in the case of failed over / slow nodes etc.), but once multiple clients are allowed to edit the value, it becomes impossible(? suggestions welcome) to tell whether we modified the value or another client did (eg. if both clients GET -> x and SET x+10). Solutions for this issue fall into more complex application logic such as pessimistic locking, or breaking down the stored value such that it can be edited idempotently (eg instead of a single balance, keep an array of transaction history that is appended to). I'll write samples for both of these examples, and any others that are suggested.

          daniel.roberts Daniel Roberts (Inactive) added a comment - As is the issue with an ambiguous response, finding out whether we've updated the value or not is in some way unknowable. In the case of a single client, we can use CAS values to determine whether or not the value has been modified by the ambiguous operation ( but not if it may still be in the future - in the case of failed over / slow nodes etc.), but once multiple clients are allowed to edit the value, it becomes impossible(? suggestions welcome) to tell whether we modified the value or another client did (eg. if both clients GET -> x and SET x+10). Solutions for this issue fall into more complex application logic such as pessimistic locking, or breaking down the stored value such that it can be edited idempotently (eg instead of a single balance, keep an array of transaction history that is appended to). I'll write samples for both of these examples, and any others that are suggested.
          tony.hillman Tony Hillman added a comment -

          Decision as per Daniel Owen is that the current account in the docs (https://docs.couchbase.com/server/6.5/learn/data/durability.html#handling-ambiguous-results) is sufficient. Further information to be provided by blogging.

          tony.hillman Tony Hillman added a comment - Decision as per Daniel Owen is that the current account in the docs ( https://docs.couchbase.com/server/6.5/learn/data/durability.html#handling-ambiguous-results)  is sufficient. Further information to be provided by blogging.

          People

            tony.hillman Tony Hillman
            shivani.gupta Shivani Gupta
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes

                PagerDuty