Summary:

I would find the availability of networked connection-owned locks hugely beneficial ... that is mutual exclusion AND blocking/waiting. Mutual exclusion is possible, but locks can be orphaned ... blocking/waiting is only made possible via polling. This could be implemented as something as "simple" as "db.aquireLock(X), db.releaseLock(X), etc".

Long version:

Mutual exclusion is very handy and can be used to improve/solve many issues somtimes faced when dealing with resources in more "complex" web services. Like generating images on-the-fly, while making sure only one process actually generates it, requires mutual exclusion... or for making sure that multiple user-requests cannot enter a race-condition and incorrectly use and modify the same session simultaenously (PHP uses file-locking for file based sessions). For the purpose of this "jira issue", there are generally two important parts to mutual exclusion:

1. Ensuring that only one "consumer" can access a "resource" at any time
2. Allowing a "consumer" to wait for a "resource" to become available

For web-services and higher-level mutual exclusion, there are generally three primary uses, "task queues" (a lot of uses), "exclusive resource access" (like sessions) and "exclusive resource generation" (like thumbnail generation).

#1 allows the implementation of all the above "uses"... but #2 is required for instant/fast notification of the completion of a task or the availability of a resource.

MongoDB currently supports #1 by way of "findAndModify" and "insert", because of the existance of safe and atomic updating of single documents. But does not support #2, it can be worked around by "busy-waiting" and continously polling the database at a (fast) fixed rate. This is certainly not ideal, both because it incurs additional overhead and also delays resource access because of the polling rate, which isn't desirable for fast tasks (as is often the case with interactive web services). Additionally, due to the lack of a native implementation, a lock would not be released if a fatal error occurs (when disconnected)... which is certainly important, but livable.

MySQL provides both #1 and #2 as well as releasing any owned locks on disconnect (one can acquire mutexes and lock tables). It is perhaps debatable whether or not a database should be "required" to facilitate such functionality, but the reality of it is that it is tremendously useful for certain problems (especially in conjuction with the GridFS-system). It sure would tie up the knot for me personally, being able to put sessions in MongoDB and efficiently taking care of resource generation and task queues.

The simplest solution being to just provide mutexes (read: db.aquireLock(X), db.releaseLock(X), etc) that are networked and connection-dependent. And there are certainly other ways of making it "integrate" more deeply with MongoDB, but that's something I don't really dare to speculate about.

... or is this something that MongoDB doesn't want to be concerned with?