Using a combination of Optimistic and Pessimistic Locking?

[lakshsubra]

Continuing the discussion from Optimistic / Pessimistic locking in 2.1.x driver:

@ingenthr

In the 2.x client, we intentionally changed the packaging structure for two reasons. One is that it’s a new major version with new API. Second is that we wanted people to be able to run the 1.x and the 2.x in the same app concurrently to facilitate slower migrations.

You can see the 2.x API in the API reference, as linked off of the documentation.

With regard to getAndLock(), it’s actually best characterized as a cooperative pessimistic lock with a timeout. What that means is as long as all code paths are using the same getAndLock() access path, only one will succeed with the lock if many actors are going after it once, and the others will then learn that it’s locked. It’s that actor’s responsibility to unlock the document with either an unlock or a CAS operation. If it doesn’t do so within a timeout period, then the lock will be released.

The CAS based optimistic locking is, of course, still there and I personally think it’s generally the preferred approach if you can refactor the problem in that way.

I usually see the getAndLock() type approach to be best used if your application is grabbing a graph of objects for update and wants reasonable assurances (with no failures) that it has exclusive access. However, it’s up to the app to handle the failure cases.

Just want to make sure I understand this correctly. Let’s suppose that there are two code paths intending to modify the same document and one does a getAndLock and the other does a get. A few questions now…

• If the latter does an upsert/replace before the former then is the lock effectively nullified?
• What happens when the former does an upsert/replace? I am assuming CAS will come into play ensuring data integrity.

In other words, for the locking mechanism to be used effectively all access to the document should use getAndLock.

Currently in one code path of our application, documents are fetched with lock, modified and written back one at a time (because contextually there is only one document that we have to deal with in this code path). In a different code path many documents need to be read, modified and written back. We are doing a bulk read, modify and bulk write for performance reasons. So, getAndLock might not be correct in this scenario.

Are there any recommendations with regards to ensuring data integrity and performance? Is using a get and handling CAS related exception the right way to go?