Create locking framework implementation

Four years later and no committed version, can we agree to close this and say there will never be a stable 6.x version for lock ?

Agreed. If there is still anyone out there that needs this feel free to reopen and bring patch to RTBC state. Maintainers will be happy to commit it in that case.

I think it makes sense to reopen this for D7.

After doing some other optimizations, the remaining sources of slow queries when flushing caches are lock_acquire(), lock_release() and variable_set(). Migrating this stuff to MongoDB probably helps.

(fyi I just started playing with MongoDB today, so maybe it will take a while until I actually write a patch)

I am trying to port this to D7.
One thing I run into is this:

Deprecated function: MongoCollection::insert(): The 'safe' option is deprecated, please use 'w' instead in lock_acquire() (line 134 of ../mongodb_lock/mongodb_lock.inc).
Deprecated function: MongoCollection::remove(): The 'safe' option is deprecated, please use 'w' instead in lock_release() (line 270 of ../mongodb_lock/mongodb_lock.inc).

According to http://php.net/manual/de/mongo.writeconcerns.php

"safe"
Deprecated. Please use the write concern "w" option.

and

"w"
See Write Concerns. The default value for MongoClient is 1.

See also http://php.net/manual/de/mongo.writeconcerns.php

I assume this means I can totally omit the 'safe' => 1, because the 'w' is already on 1 by default.
Can someone confirm this?

Another question is whether this really needs to be a separate submodule, or if it is sufficient to just have the include file, like in memcache-lock.inc and memcache-lock-code.inc.

Actually, any operation should use the settings from the connection, and in most cases only override them in a way that can be configured, so it doesn't seem to make much sense to hardcode a write concern like this, be it the old way (safe) or the new one (w, j).

Regarding the "submodule", I think the main reason for having them is to keep each concern in its own "area" using directories. One small thing, by the way : I would prefer you to use .php files rather than .inc in future code, so they can be included in the Scrutinizer checks. And PSR-4 if there are classes : there is already a PSR-4 autoloader in one of the current issues/branches, which is likely to help when we'll tackle D8.

Just so we have a new starting point for further work on this.
Or maybe it is already good this way :)

I am running this locally and have not seen any issues, but I don't really know what to look for.

The D6 patch from #7 applied cleanly to D7 (because it was all about adding files), so I started with that.
Further changes can be seen on github,
https://github.com/donquixote/drupal-mongodb/compare/7.x-1.x...7.x-1.x-l...

Good to have a starting point. It will need tests, of course : you can look at the way to have usable tests for MongoDB with Simpletest in the recently updated submodules as well as the yet unmerged path plugin issue.

Rerolled on today's 7.x-1.x HEAD. Still needs improvements though. At a minimum:

* Update the README.md
* Provide tests, probably by wrapping the core tests just like the cache plugin does.

PR is on https://github.com/fgm/mongodb/pull/66