[SPY-128] Support CAS for delete operation Created: 04/Dec/12  Updated: 19/Jul/13  Resolved: 19/Jul/13

Status: Resolved
Project: Spymemcached Java Client
Component/s: library
Affects Version/s: None
Fix Version/s: 2.9.1
Security Level: Public

Type: New Feature Priority: Major
Reporter: schp Assignee: Michael Nitschinger
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JCBC-193 Allow CAS with delete Closed

 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.

 Comments   
Comment by Michael Nitschinger [ 04/Dec/12 ]
Thanks for your input!

I'll discuss this and then get back to you in this ticket!
Comment by Michael Nitschinger [ 19/Dec/12 ]
What do you think about this?
Comment by Matt Ingenthron [ 19/Dec/12 ]
I do think it makes sense, and it's in there actually for operations with durability requirements.
Comment by Ricky Martin [ 17/Jun/13 ]
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.
Comment by Michael Nitschinger [ 25/Jun/13 ]
http://review.couchbase.org/#/c/27107
Comment by Michael Nitschinger [ 25/Jun/13 ]
moving it over to SPY because its implemented in spymemcached
Comment by Ricky Martin [ 07/Jul/13 ]
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?
Comment by Michael Nitschinger [ 19/Jul/13 ]
Ricky, please see SPY-129!
Generated at Sun Apr 20 04:27:37 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.