Locking using Couchbase and Spy Memcached API
Reading the artical here: http://www.couchbase.org/wiki/display/membase/Locking, I tried to implement locking on our system. We need locking as we have to generate unique ID's used as referances on invoices. These much be short so people can write them down, but unique so they don't get mixed up with other invoices.
So reading the artical above and implementing the following code snippet:
String lockObject = "LOCK_OBJECT";
couchbaseClient.add("lockName", 10, lockObject);
couchbaseClient.add("lockName", 10, lockObject);
you would think the second method would throw an exception/lock/or fail in some other way. Except it dosn't. Both method run and execute fine.
So am I reading the document above in correctly, or does it not apply to Couchbase?
We are using spymemcached version 2.8-preview2, and Couchbase Server Version: 2.0.0r-1-ge4c8742
Any ideas anyone about implementing locking?
Thanks
Adam
UPDATE:
So after a bit of digging found a solution:
OperationFuture<boolean> result = couchbaseClient.add(lockName, LOCK_EXPIRE_TIME, LOCK_OBJECT); OperationStatus status = result.getStatus(); if(!status.isSuccess()){ // Assume data is in the system System.out.println("" + status.getMessage()); } </boolean>
However, not entirly satified because I assume the status.isSucess() can return false for any number of reasons. The status.getMessage() returns a message such as "Data exists for Ðí5" but parsing this message does not seem like a good way forward.
I guess the working assumption should be to assum that status.isSucess() == false means that data is already there.
Adam
Adam, I'll answer this here and let a spy expert chime in if necessary.
I think you've hit on the issue here. In spy, all of these operations return a "future" which is only telling you that the operation was sent to the database. You'll need to check the status of the future in order to determine whether the actual operation succeeded or failed.
A failure for status.isSucess() most likely means that the data is already there (for an add operation), but it's safe to assume that there are other reasons an operation could fail. However, a failure in this case does guarantee that your app was unable to acquire the lock.
Going a bit deeper, I'd like to understand why you need the lock in this case. We typically only recommend using this when you need to control access to multiple items at once. If that's not the case here, there may be other strategies that suit your needs (such as using CAS).
Perry
Forum support is great for free but sometimes you need a guaranteed response time and dedicated resources for your questions or issues.
Consider purchasing enterprise-level support from Couchbase: http://www.couchbase.com/products-and-services/overview
Call or email "sales -at- couchbase-dot- com" today!