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.

        Issue Links

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

          Activity

          schp schp created issue -
          daschl Michael Nitschinger made changes -
          Field Original Value New Value
          Fix Version/s 1.1.0 [ 10274 ]
          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!
          daschl Michael Nitschinger made changes -
          Fix Version/s 1.1.1 [ 10430 ]
          Fix Version/s 1.1.0 [ 10274 ]
          daschl Michael Nitschinger made changes -
          Link This issue is duplicated by JCBC-193 [ JCBC-193 ]
          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?
          daschl Michael Nitschinger made changes -
          Assignee Michael Nitschinger [ daschl ] Matt Ingenthron [ ingenthr ]
          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.
          ingenthr Matt Ingenthron made changes -
          Assignee Matt Ingenthron [ ingenthr ] Michael Nitschinger [ daschl ]
          daschl Michael Nitschinger made changes -
          Fix Version/s 1.1.2 [ 10480 ]
          Fix Version/s 1.1.1 [ 10430 ]
          daschl Michael Nitschinger made changes -
          Fix Version/s 1.1.3 [ 10496 ]
          Fix Version/s 1.1.2 [ 10480 ]
          daschl Michael Nitschinger made changes -
          Fix Version/s 1.1.4 [ 10514 ]
          Fix Version/s 1.1.3 [ 10496 ]
          daschl Michael Nitschinger made changes -
          Planned Start (set to new fixed version's start date)
          Planned End (set to new fixed version's start date)
          daschl Michael Nitschinger made changes -
          Fix Version/s 1.1.5 [ 10515 ]
          Fix Version/s 1.1.4 [ 10514 ]
          daschl Michael Nitschinger made changes -
          Planned Start (set to new fixed version's start date)
          Planned End (set to new fixed version's start date)
          daschl Michael Nitschinger made changes -
          Fix Version/s 1.1.6 [ 10531 ]
          Fix Version/s 1.1.5 [ 10515 ]
          daschl Michael Nitschinger made changes -
          Rank Ranked higher
          daschl Michael Nitschinger made changes -
          Sprint Sprint 1 - CW 19 & 20 [ 13 ]
          daschl Michael Nitschinger made changes -
          Fix Version/s 1.1.7 [ 10532 ]
          Fix Version/s 1.1.6 [ 10531 ]
          daschl Michael Nitschinger made changes -
          Fix Version/s 1.1.8 [ 10628 ]
          Fix Version/s 1.1.7 [ 10532 ]
          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
          daschl Michael Nitschinger made changes -
          Project Couchbase Java Client [ 10080 ] Spymemcached Java Client [ 10047 ]
          Key JCBC-164 SPY-128
          Affects Version/s 1.1-beta [ 10370 ]
          Fix Version/s 2.9.1 [ 10627 ]
          Fix Version/s 1.1.8 [ 10628 ]
          Component/s library [ 10120 ]
          Component/s library [ 10140 ]
          daschl Michael Nitschinger made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          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?
          daschl Michael Nitschinger made changes -
          Fix Version/s 2.9.2 [ 10905 ]
          Fix Version/s 2.9.1 [ 10627 ]
          daschl Michael Nitschinger made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Fix Version/s 2.9.1 [ 10627 ]
          Fix Version/s 2.9.2 [ 10905 ]
          Resolution Fixed [ 1 ]
          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:

                Agile

                  Gerrit Reviews

                  There are no open Gerrit changes