Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.9.1
    • Component/s: library
    • Security Level: Public
    • Labels:
      None
    • Sprint:
      Sprint 1 - CW 19 & 20

      Description

      It would be nice if the DELETE operation would support a CAS parameter, a feature which is available in e. g. the Ruby client library. Without the possibility for checking for a given CAS value it may happen that a DELETE removes a key-value pair which was just updated by an other thread.

        Attachments

          Issue Links

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

            Activity

            Hide
            daschl Michael Nitschinger added a comment -

            Thanks for your input!

            I'll discuss this and then get back to you in this ticket!

            Show
            daschl Michael Nitschinger added a comment - Thanks for your input! I'll discuss this and then get back to you in this ticket!
            Hide
            daschl Michael Nitschinger added a comment -

            What do you think about this?

            Show
            daschl Michael Nitschinger added a comment - What do you think about this?
            Hide
            ingenthr Matt Ingenthron added a comment -

            I do think it makes sense, and it's in there actually for operations with durability requirements.

            Show
            ingenthr Matt Ingenthron added a comment - I do think it makes sense, and it's in there actually for operations with durability requirements.
            Hide
            rickyepoderi Ricky Martin added a comment -

            It would be really nice, cos delete with a CAS is the only way of deleting a locked object. In my tests, under some circumstances, if the object is first unlocked and then deleted, weird things could happen (race condition). So please I need this feature in order to preserve correct locking.

            Show
            rickyepoderi Ricky Martin added a comment - It would be really nice, cos delete with a CAS is the only way of deleting a locked object. In my tests, under some circumstances, if the object is first unlocked and then deleted, weird things could happen (race condition). So please I need this feature in order to preserve correct locking.
            Show
            daschl Michael Nitschinger added a comment - http://review.couchbase.org/#/c/27107
            Hide
            daschl Michael Nitschinger added a comment -

            moving it over to SPY because its implemented in spymemcached

            Show
            daschl Michael Nitschinger added a comment - moving it over to SPY because its implemented in spymemcached
            Hide
            rickyepoderi Ricky Martin added a comment -

            Hi Michael,

            I have tested the new version 2.9.1 (I see that the delete method with cas is there) and it still fails to delete a locked object. It works with a gets and then a delete (this works without problem) but not with a lock and then a delete. So I cannot delete a locked object with this patch. My code is very simple:

            URI base = new URI("http://localhost:8091/pools");
            ArrayList baseURIs = new ArrayList();
            baseURIs.add(base);
            client = new CouchbaseClient(baseURIs, "default", null, "");
            String key = "dd2982ff68406c937040cd0c509b";
            System.err.println("Creating the object");
            OperationFuture<Boolean> addFuture = client.add(key, 300, "lala");
            System.err.println("Status add: " + addFuture.getStatus());
            System.err.println("Getting and locking the object");
            OperationFuture<CASValue<Object>> future = client.asyncGetAndLock(key, 30);
            System.err.println("Status getl: " + future.getStatus());
            if (!future.getStatus().isSuccess())

            { throw new Exception("Error locking!!!!"); }

            System.err.println("Lock is mine");
            System.err.println("Status getl: " + future.get());
            System.err.println("delete");
            OperationFuture<Boolean> future4 = client.delete(key, future.get().getCas());
            System.err.println("delete: " + future4.getStatus());
            if (!future4.getStatus().isSuccess())

            { throw new Exception("Error deleting!!!"); }

            The error is: "Temporary failure". If the getAndLock is substituted by an asyncGets it works perfectly.

            Is this error something that is going to be fixed in another bug? is this one still in progress?

            Show
            rickyepoderi Ricky Martin added a comment - Hi Michael, I have tested the new version 2.9.1 (I see that the delete method with cas is there) and it still fails to delete a locked object. It works with a gets and then a delete (this works without problem) but not with a lock and then a delete. So I cannot delete a locked object with this patch. My code is very simple: URI base = new URI("http://localhost:8091/pools"); ArrayList baseURIs = new ArrayList(); baseURIs.add(base); client = new CouchbaseClient(baseURIs, "default", null, ""); String key = "dd2982ff68406c937040cd0c509b"; System.err.println("Creating the object"); OperationFuture<Boolean> addFuture = client.add(key, 300, "lala"); System.err.println("Status add: " + addFuture.getStatus()); System.err.println("Getting and locking the object"); OperationFuture<CASValue<Object>> future = client.asyncGetAndLock(key, 30); System.err.println("Status getl: " + future.getStatus()); if (!future.getStatus().isSuccess()) { throw new Exception("Error locking!!!!"); } System.err.println("Lock is mine"); System.err.println("Status getl: " + future.get()); System.err.println("delete"); OperationFuture<Boolean> future4 = client.delete(key, future.get().getCas()); System.err.println("delete: " + future4.getStatus()); if (!future4.getStatus().isSuccess()) { throw new Exception("Error deleting!!!"); } The error is: "Temporary failure". If the getAndLock is substituted by an asyncGets it works perfectly. Is this error something that is going to be fixed in another bug? is this one still in progress?
            Hide
            daschl Michael Nitschinger added a comment -

            Ricky, please see SPY-129!

            Show
            daschl Michael Nitschinger added a comment - Ricky, please see SPY-129 !

              People

              • Assignee:
                daschl Michael Nitschinger
                Reporter:
                schp schp
              • Votes:
                1 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Gerrit Reviews

                  There are no open Gerrit changes