jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: Concurrency Question
Date Wed, 30 Jan 2013 09:06:27 GMT
Hi,
Thanks for educating me, that makes sense.

Is the one collection that can't be sharded the one holding the root
of the repo ?
(my oak terminology might not be right, sorry)

Ian


On 30 January 2013 19:53, Thomas Mueller <mueller@adobe.com> wrote:
> 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" <ieb@tfd.co.uk> 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
>

Mime
View raw message