Hi, As far as I understand, this was within one shard and replica (one mongod). See also: http://www.infoq.com/news/2010/08/MongoDB-1.6
For scalable writes, we would need to write concurrently to different shards. Even if all operations within one shard are synchronized (and I don't think that's the case), Oak would still be scalable. Concurrent operations within one mongod might improve performance / throughput however. The current MongoMK does have a scalability problem in my view, because there is at least one collection that can't be sharded. But I guess this is something we need to solve anyway, if we really want to have a scalable solution. Regards, Thomas On 1/29/13 11:42 PM, "Ian Boston" <[email protected]> wrote: >Hi, >Are the concurrency characteristics of MongoDB [1] relevant to write >concurrency in Oak ? > >IIUC from the presentation MongoDB pre 2.2 had global exclusive write >locks and post 2.2 has per database exclusive write locks which might >be scoped to the shard if the update only impacts a single shard. > >I am assuming that any storage implementation for Oak won't rely on >this characteristic and could use a less synchronised storage >mechanism from one of the other providers ? > >I ask, because I don't know if this is relevant, and want to be educated. > >Thanks >Ian > >1 http://www.10gen.com/presentations/concurrency-internals-mongodb-v22
