<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 02:56:28 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[SERVER-1240] Collection-level locking</title>
                <link>https://jira.mongodb.org/browse/SERVER-1240</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description></description>
                <environment></environment>
        <key id="12157">SERVER-1240</key>
            <summary>Collection-level locking</summary>
                <type id="3" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14718&amp;avatarType=issuetype">Task</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="9">Done</resolution>
                                        <assignee username="eliot">Eliot Horowitz</assignee>
                                    <reporter username="eliot">Eliot Horowitz</reporter>
                        <labels>
                    </labels>
                <created>Tue, 15 Jun 2010 11:23:55 +0000</created>
                <updated>Thu, 2 Aug 2018 21:21:16 +0000</updated>
                            <resolved>Wed, 22 Oct 2014 23:22:55 +0000</resolved>
                                                    <fixVersion>2.7.8</fixVersion>
                                    <component>Concurrency</component>
                                        <votes>387</votes>
                                    <watches>293</watches>
                                                                                                                <comments>
                            <comment id="517276" author="stennie" created="Mon, 17 Mar 2014 10:43:34 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=ben.brockway%40nxtera.com&quot; class=&quot;user-hover&quot; rel=&quot;ben.brockway@nxtera.com&quot;&gt;ben.brockway@nxtera.com&lt;/a&gt;: the new &lt;a href=&quot;http://docs.mongodb.org/master/core/index-intersection/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;index intersection&lt;/a&gt; feature is mentioned in the 2.6 release notes under &lt;a href=&quot;http://docs.mongodb.org/master/release-notes/2.6/#query-engine-improvements&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;Query Engine Improvements&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;If anyone has further questions on MongoDB 2.6 or other topics, can you please post to the &lt;a href=&quot;https://groups.google.com/forum/#!forum/mongodb-user&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;mongodb-user discussion group&lt;/a&gt;? Comments on this Jira issue should be kept relevant to the &quot;collection level locking&quot; feature request, and your questions will also have more visibility on the community forum.&lt;/p&gt;

&lt;p&gt;Thanks,&lt;br/&gt;
Stephen&lt;/p&gt;</comment>
                            <comment id="517270" author="ben.brockway@nxtera.com" created="Mon, 17 Mar 2014 10:00:35 +0000"  >&lt;p&gt;@Eliot Horowitz - Is there any updated documentation to support the multi-index queries enhancement that you mention? I would quite like to understand how it works as it may be incredibly beneficial for me. I can&apos;t see any information on this in the 2.6 docs (yet). Thanks&lt;/p&gt;</comment>
                            <comment id="517246" author="climax" created="Mon, 17 Mar 2014 07:26:54 +0000"  >&lt;p&gt;I made the mistake to assume that locking was the bottleneck. I tried TokuMX, and found no improvement, perhaps only a little better concurrency and smaller footprint. Upon further benchmarking, profiling and testing I found that it was my own bad design which led to the bad performance. Furthermore, I would not recommend TokuMX as it is currently prone to crashes on a &quot;Stable&quot; release.&lt;/p&gt;

&lt;p&gt;I&apos;ve been getting much (10-20%) improved performance with the new 2.6.0-rc0 branch.&lt;/p&gt;</comment>
                            <comment id="492783" author="rogerbinns" created="Tue, 4 Feb 2014 02:22:42 +0000"  >&lt;p&gt;We are also going to have to change database engines because of MongoDB&apos;s pitiful locking contention and performance. I&apos;d love to see some hints as to what these &quot;lots of methods&quot; are since I can only see three:&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Make each document bigger instead of several smaller ones&lt;/li&gt;
	&lt;li&gt;Use more databases&lt;/li&gt;
	&lt;li&gt;Use more machines (shards)&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I did try TokuMX about a month ago.  It had drastically smaller database size (mongodump bson was ~360GB, Toku only needed 53GB including indexes to store that).  The import and index generation was a lot faster too.  However it fell over with an internal locking error when running an overnight job (about 100:1 reads versus writes).&lt;/p&gt;
</comment>
                            <comment id="492389" author="tubededentifrice" created="Mon, 3 Feb 2014 18:22:09 +0000"  >&lt;p&gt;I never heard about TokuMX, but now I simply hope MongoDB, Inc will use their $150M to buy that little company or integrate their changes (why not, as they are open sourced!).&lt;br/&gt;
This request (collection level locking) was created almost 4 years ago! And it is still not even planned yet...&lt;/p&gt;</comment>
                            <comment id="492129" author="eliot" created="Mon, 3 Feb 2014 09:52:09 +0000"  >&lt;p&gt;Hi,&lt;br/&gt;
Speaking to the higher level issue of write scalability, there are a number of things going on right now.&lt;/p&gt;

&lt;p&gt;While 2.6 doesn&apos;t address lock granularity specifically, it has a lot lot work for write scalability and prep work that sets the stage for lock granularity work.&lt;/p&gt;

&lt;p&gt;A couple of things in 2.6 that impact write scalability.&lt;br/&gt;
The new query execution engine uses multiple indexes for a single query, which in many cases greatly reduces the number of indexes needed (which is the largest impediment to write scaling).&lt;br/&gt;
Much of the work we used to do inside locks is now pulled out, such as query and update parsing and _id generation.&lt;br/&gt;
We&apos;ve done a lot of work on improving oplog write concurrency, both by making each write faster and changing the locking around how this works.  This improves concurrency in 2.6, but also was required before more granular locking would be beneficial or it would immediately bottleneck everything.&lt;/p&gt;

&lt;p&gt;Of course lock granularity is also critical. 2.8 will definitely have finer grained locking, the specifics of which we&apos;ll lock down over the next couple of months.&lt;/p&gt;

&lt;p&gt;In the meantime, there are lots of methods for increasing write scalability, so if anyone opens a new ticket, happy to help in a specific case.&lt;/p&gt;

&lt;p&gt;-Eliot&lt;/p&gt;</comment>
                            <comment id="492092" author="msalvado" created="Mon, 3 Feb 2014 03:26:03 +0000"  >&lt;p&gt;From what it&apos;s worth, form a project that recently quit mongoDB for a competitor, my advice would be to quickly change the way you address your community needs and the way you expose your technical vision and strategy to your community. I can&apos;t believe that this particular issue has not been addressed yet. We&apos;re in 2014, people no longer stick to a tech for a lifetime. We now choose the best tool for the usage at a particular time, and we don&apos;t hesitate to migrate in the middle of the life of a product for another technology, when it addresses our business requirements and operational needs. It&apos;s too bad because I still find MongoDB has great features, it&apos;s just too limited right now when it comes to scaling writes.&lt;/p&gt;</comment>
                            <comment id="492079" author="dreammaker" created="Mon, 3 Feb 2014 02:00:24 +0000"  >&lt;p&gt;Please, do not keep silent, say when will you tell about plans? Like many people here  I have been waiting long time but I shall change the database to TokuMX in few next months if MongoDB does not have the document-level locking as well as TokuMX has.&lt;/p&gt;</comment>
                            <comment id="486071" author="tubededentifrice" created="Wed, 22 Jan 2014 22:03:01 +0000"  >&lt;p&gt;Could we have some sort of ETA for this? It&apos;s particularly problematic when you have small multicores CPU (say 2 cores/4 threads with hyperthreading, like an Atom N2800 or something), because it tends to be CPU bound (in my case secondaries can&apos;t keep up with updates because of this, MongoDB is using a single of the 4 apparent cores (ie 1/2 to 1/4 of the total CPU power), leading to incredibly poor performances &amp;#8211; however primaries are fine with lower - but high - CPU usages, don&apos;t really understand why).&lt;br/&gt;
I&apos;m considering moving collections to different databases, but that&apos;s a real pain to manage (not a big deal to do at the beginning, but managing the change is the real big deal).&lt;/p&gt;</comment>
                            <comment id="459704" author="geert.pante@persgroep.be" created="Thu, 21 Nov 2013 13:51:37 +0000"  >&lt;p&gt;I&apos;m not sure if this is the correct issue.&lt;/p&gt;

&lt;p&gt;My use case is the following:&lt;br/&gt;
We have two collections: tweet_share and access_log where we log filtered tweets and access logs for a big online newspaper. We have two aggregators that reads from these collections and summarizes per article by 10-minute interval, hour, day, month, and store these results in a third collection. If these collections are in the same database, writing access log entries is slowed down by writing aggregate results from the twitter collection to the summary collection and vice versa.&lt;/p&gt;

&lt;p&gt;If we put each collection in a separate database, throughput is much higher. This is harder to manage, but it works... &lt;/p&gt;

&lt;p&gt;Please make the write lock only holds for one collection at a time.&lt;br/&gt;
Is this the correct issue for this use case?&lt;/p&gt;</comment>
                            <comment id="405701" author="rhat" created="Sun, 18 Aug 2013 13:51:22 +0000"  >&lt;p&gt;I would very much appreciate this.&lt;br/&gt;
A possible use case for this is given in the docs:&lt;br/&gt;
&lt;a href=&quot;http://docs.mongodb.org/manual/use-cases/metadata-and-asset-management/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://docs.mongodb.org/manual/use-cases/metadata-and-asset-management/&lt;/a&gt;&lt;br/&gt;
Think of a multi tenant CMS with this design and a collection (did I hear &quot;bin&quot;?!) for each tenant.&lt;br/&gt;
In such a scenario, the collections are completely isolated and consistency must&lt;br/&gt;
only be assured on a collection level.&lt;/p&gt;</comment>
                            <comment id="387676" author="vivekbajpai" created="Wed, 24 Jul 2013 10:26:41 +0000"  >&lt;p&gt;I have also the same issue with collection level locking.It takes so many time to read and write on the same collection.In log it can be easily traced.&lt;br/&gt;
 nscanned:4 nupdated:2 keyUpdates:4 numYields: 1 locks(micros) w:2461970 10275ms&lt;br/&gt;
 nscanned:4 nupdated:2 keyUpdates:3 numYields: 1 locks(micros) w:2475463 8847ms&lt;br/&gt;
collection have only 70000 document but concurrent reads are high so updating a single document some time take more than 10 sec.&lt;br/&gt;
Any idea how to resolve it.&lt;br/&gt;
what i hv already done &lt;br/&gt;
1.Replication with sharding using 3 member replica set collection level sharding is also enable.&lt;br/&gt;
2.Each member placed in EC2 Medium instance.&lt;br/&gt;
3.Query is also bounded with indexes.&lt;/p&gt;




</comment>
                            <comment id="373022" author="kradski" created="Tue, 2 Jul 2013 23:52:57 +0000"  >&lt;p&gt;Given the default behavior of client libraries to return from a write as fast as possible and let the write happen in the background, I&apos;m semi-concerned this might eventually get exploited by attackers in certain situations.&lt;/p&gt;

&lt;p&gt;An example:&lt;/p&gt;

&lt;p&gt;1. Your database is `mydb`. (all write locks hit this).&lt;br/&gt;
2. Your user table is User within `mydb`.&lt;br/&gt;
3. `User` has a field for &quot;signature&quot; or something else easily/readily changeable by a user.&lt;br/&gt;
4. Attacker repeatedly changes the field over and over again, as fast as possible. Multithread or otherwise distribute the requests.  The web server still returns very quickly, masking the actual overhead of the write.&lt;br/&gt;
5. Reads on `mydb` by other clients increasingly become blocked by the resultant write locks, bringing the site to a standstill with relative ease.&lt;/p&gt;

&lt;p&gt;Obviously you could mitigate the issue at the application level (e.g., rate-limiting, captchas, setting the flag to force journal flushing/write acks, etc...) or by restructuring to use multiple databases (still won&apos;t mitigate the same single PoF if someone&apos;s using pseudo-joins or another collection within the database needs frequent accessing).&lt;/p&gt;

&lt;p&gt;It might be an idea to allow &quot;unsafe reads&quot; of some sort that can read through a write lock, but this would, at the very minimum, require updates to client libraries to support find() query flags (not to mention probably have implications in sharding).&lt;/p&gt;

&lt;p&gt;Obviously this isn&apos;t as much an issue for infrequently updated or non-public-servicing databases, but at the very least, it makes sense that collection-level (and ideally, document-level) locking should be considered increasingly important--that is, if I&apos;m understanding the current state of them correctly.&lt;/p&gt;</comment>
                            <comment id="336429" author="eliot" created="Wed, 15 May 2013 18:38:22 +0000"  >&lt;p&gt;We&apos;re definitely working on this, its just in pieces.&lt;/p&gt;

&lt;p&gt;Additionally, the cases we&apos;re generally seeing now (after the changes in 2.0 -&amp;gt; 2.4) wouldn&apos;t be helped by this as much as other changes related to concurrency around journalling, replication and sub-collection.&lt;/p&gt;

&lt;p&gt;Can you describe the use case and what you&apos;re seeing?  Want to make sure collection level locking is the right solution.&lt;/p&gt;

&lt;p&gt;Fred: for example, what version are you on and can you send the logs for a sample?  &lt;br/&gt;
Maybe a subticket of this ticket would be good.&lt;/p&gt;</comment>
                            <comment id="336395" author="colombiunpride" created="Wed, 15 May 2013 18:17:42 +0000"  >&lt;p&gt;I&apos;ve been following this specific ticket for a while now. It&apos;s the ONLY reason we backed out from using MongoDB in a production environment. I&apos;m sure it&apos;s not an easy fix, but we moved to Couchbase 2.0 because of it. &lt;/p&gt;</comment>
                            <comment id="334820" author="fredr313" created="Mon, 13 May 2013 21:33:52 +0000"  >&lt;p&gt;Why is this not being worked on? We are constantly constrained by locking. mongostat is always reporting lock percentages between 50-100%. This design is super, super frustrating. This is the 2nd most requested feature/bug fix. We don&apos;t need new features if basic DB functionality won&apos;t work.&lt;/p&gt;</comment>
                            <comment id="317328" author="chengas123" created="Fri, 19 Apr 2013 21:36:24 +0000"  >&lt;p&gt;This is a really frustrating issue. Any update on updating from &quot;Planning Bucket A&quot; to a scheduled release?&lt;/p&gt;</comment>
                            <comment id="302227" author="mcatanzariti" created="Sat, 30 Mar 2013 12:37:27 +0000"  >&lt;p&gt;Hi Kevin J. Rice,&lt;/p&gt;

&lt;p&gt;I was wondering with a setup of multiple shards on the same machine if the mongod processes would not fight for memory. Especially if the data working set is larger than the amout of available RAM on the server.&lt;/p&gt;</comment>
                            <comment id="300727" author="lifer" created="Thu, 28 Mar 2013 13:24:14 +0000"  >&lt;p&gt;Hello guys!&lt;br/&gt;
We are using MongoDB, and now we have faced this issue with database locks. Can you update me with current estimates of collection level locking implementation? &lt;br/&gt;
I&apos;m asking because we need to decide, should we move each collection into different database, or just wait a while for collection level locking to be done.&lt;/p&gt;

&lt;p&gt;Thanks in advance.&lt;/p&gt;</comment>
                            <comment id="276408" author="justanyone" created="Tue, 26 Feb 2013 19:14:48 +0000"  >&lt;p&gt;Echo Vadim almost:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;lots of 4k docs in one collection;&lt;/li&gt;
	&lt;li&gt;locking is huge slowdown (induces delay in updates of single documents);&lt;/li&gt;
	&lt;li&gt;have 2 servers primary plus 2 servers for replicasets.&lt;/li&gt;
	&lt;li&gt;Achieved MASSIVE improvement of performance (Mongo 2.2.1) using 24 shards (12 each on 2 servers).&lt;/li&gt;
	&lt;li&gt;Improvment on scale of: max 8 writers w/ 12 shards; max 28 writers with 24 shards.&lt;/li&gt;
	&lt;li&gt;Now trying 48 shards, but running into max connections problems, so may go down to 24.&lt;/li&gt;
	&lt;li&gt;Note, MUST adjust oplogsize since 5% each * 24 per server &amp;gt; 100% disk space for oplogs alone (yuck, but easy to fix).&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;UPDATE:  48 shards works, but having to add virtual IP addresses to split the number of connections to any one IP to ensure we&apos;re less than 64K of &apos;em.&lt;/p&gt;</comment>
                            <comment id="206910" author="happysoft" created="Wed, 5 Dec 2012 08:23:42 +0000"  >&lt;p&gt;Sorry for absence of statistics, precise numbers, but I surely can say the following things.&lt;br/&gt;
I&apos;m using sharding with one big collection (&amp;gt;350m docs) divided on two servers and few non-sharded collections left on primary shard.&lt;br/&gt;
There are many inserts/updates/reads against big collection and due to this workload other non-sharded collections very suffer on simple reads (it was annoying to see that querying document from non-sharded collection by _id took more 100ms). This problem was solved by moving primary to third server.&lt;/p&gt;</comment>
                            <comment id="176584" author="eliot" created="Thu, 18 Oct 2012 13:26:23 +0000"  >&lt;p&gt;With all of the changes in 2.2, would be great to see examples in 2.2 of any issues.&lt;br/&gt;
Not sure collection level locking really is the best next step as with the yielding, db locks, and other changes, at a disk level there is often only locking around single records.&lt;/p&gt;

&lt;p&gt;So if anyone watching this ticket has any locking issues in 2.2, would be great to see them.&lt;/p&gt;</comment>
                            <comment id="176581" author="turneliusz" created="Thu, 18 Oct 2012 13:23:24 +0000"  >&lt;p&gt;Crossing my fingers to see this feature, I would want to use MongoDB more!&lt;/p&gt;</comment>
                            <comment id="170457" author="defcube" created="Tue, 2 Oct 2012 17:33:57 +0000"  >&lt;p&gt;@Valery makes some good points that I can relate to. I run a large site (alexa rank 800). We started using mongodb about 5 months ago for modeling follower lists. We&apos;re now considering migrating away from mongo because of the locking issues we&apos;ve been facing. &lt;/p&gt;

&lt;p&gt;With a standard SQL solution we don&apos;t get all of the JSON goodness that I love about mongo. What we do get is a server that can easily utilize multiple CPU cores without us needing to be concerned with sharding our data set. &lt;/p&gt;

&lt;p&gt;It&apos;s very unfortunate that our mongo experiment may end as a failure, and when Valery offers you guys some necessary suggestions he gets called a troll. I hope mongo has a more mature community than Matt would make it appear. &lt;/p&gt;</comment>
                            <comment id="147064" author="vak" created="Wed, 25 Jul 2012 11:27:59 +0000"  >&lt;p&gt;@Dwight, thanks for reply and for your great contributions to MongoDB project.&lt;/p&gt;

&lt;p&gt;Well, I have 50 collections &quot;only&quot;, but also several DBs. Multiplying the DB count will involve a lot of (unneeded?) re-engineering. &lt;/p&gt;

&lt;p&gt;Regarding yielding: I&apos;ve terminated the 2-hour long remove and then the count-query immediately succeeded. &lt;/p&gt;

&lt;p&gt;TBH, it is still quite a pity that this issue is scheduled for 2.4 only. Dwight, i&apos;m sorry for my long comment and a low amount of positivism, but I still wouldn&apos;t change a lot in that comment.&lt;/p&gt;</comment>
                            <comment id="147056" author="dwight_10gen" created="Wed, 25 Jul 2012 10:50:56 +0000"  >&lt;p&gt;@Valery consider using 2.2 and a db per collection (if you have a few collecitons) or bucketing your collections into N dbs to get some more concurrency if you have say, 5000 collections.  2.2rc0 is out so it&apos;s almost there.&lt;/p&gt;

&lt;p&gt;from the snippeted output i can&apos;t tell if the problem has anything to do with concurrency. if the remove is (by intent) doing a large table scan, it will yield as it goes along, albeit it will take a long time to run if millions or billions of documents. i swould suggest discussing tunings in the support forums.&lt;/p&gt;</comment>
                            <comment id="147027" author="mattparlane" created="Wed, 25 Jul 2012 08:32:53 +0000"  >&lt;p&gt;Valery, I&apos;m getting sick of your trolling &amp;#8211; shut up.&lt;/p&gt;

&lt;p&gt;The 10gen guys have been very clear about their plans, db-level locking in 2.2 and collection-level locking in 2.4.&lt;/p&gt;

&lt;p&gt;The pace of development is hugely impressive here, and you&apos;re also getting it for free so you have no right to complain.&lt;/p&gt;</comment>
                            <comment id="147026" author="vak" created="Wed, 25 Jul 2012 08:27:51 +0000"  >&lt;p&gt;Guys, honestly, doing my best to stay positively tuned. But such a 2 years issue is a killer for thousands success stories. I don&apos;t know who sets prios on your side, but this issue is a huge fail. Pass my comment to this your &quot;Steve Jobs&quot;, please.&lt;/p&gt;

&lt;p&gt;Come on, guys, you created a great product, so why to ruin success this way? Frankly, was it &lt;b&gt;that&lt;/b&gt; hard?&lt;/p&gt;

&lt;p&gt;i have had one hour for meditations, but am still waiting:&lt;br/&gt;
db.currentOp();==&amp;gt;&lt;br/&gt;
{&lt;br/&gt;
...&lt;br/&gt;
&quot;lockType&quot; : &quot;read&quot;,&lt;br/&gt;
&quot;waitingForLock&quot; : true,&lt;br/&gt;
&quot;secs_running&quot; : 4128,&lt;br/&gt;
&quot;ns&quot; : &quot;mydb.collection_A&quot;,&lt;br/&gt;
&quot;query&quot; : {&lt;br/&gt;
&quot;count&quot; : &quot;collection_A&quot;,&lt;br/&gt;
...&lt;br/&gt;
}&lt;br/&gt;
{&lt;br/&gt;
&quot;lockType&quot; : &quot;write&quot;,&lt;br/&gt;
&quot;waitingForLock&quot; : false,&lt;br/&gt;
&quot;secs_running&quot; : 6724,&lt;br/&gt;
&quot;op&quot; : &quot;remove&quot;,&lt;br/&gt;
&quot;ns&quot; : &quot;mydb.collection_B&quot;,&lt;br/&gt;
...&lt;br/&gt;
}&lt;/p&gt;

&lt;p&gt;guys, what you hear is totally unhappy voice. I do understand, that being totally unhappy is a clear sign of my personal failure in &lt;b&gt;my&lt;/b&gt; &lt;b&gt;own&lt;/b&gt; wrong expectation. However, don&apos;t miss your part of my failure &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/wink.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; &lt;br/&gt;
1. MongoDB was never sending signals like &apos;we are building academical experimental products please don&apos;t use it in real-life applications!&quot;&lt;br/&gt;
2. &quot;collection level locking&quot; was a very basic high impact expectation. &lt;br/&gt;
3. MongoDB guys are too cool to build such a broken architecture, where &quot;collection level locking&quot; is hard to implement in 2 years. &lt;/p&gt;

&lt;p&gt;Looks right?&lt;/p&gt;

&lt;p&gt;And don&apos;t tell me about &quot;we are open source&quot;, etc. If it was any lack of resources and/or problems, why didn&apos;t you inform us in last two years? I&apos;m quite sure people (and poor me) would have proposed solutions. Also, don&apos;t tell me about things that have to fit in RAM, I have &lt;b&gt;terabytes&lt;/b&gt; of data and I do fight for RAM.&lt;/p&gt;

&lt;p&gt;Last but not least, nice google trend for MongoDB should be a signal for you, that great success comes with great responsibility. No matter what is your business model and how steep is your growth right now.&lt;/p&gt;

&lt;p&gt;Please, release this feature ASAP.&lt;/p&gt;

&lt;p&gt;P.S. devs that work hard on closing the prioritized issues are not addressed (thank you guys!). Those who set prios are addressed only.&lt;/p&gt;

&lt;p&gt;Thanks.&lt;/p&gt;</comment>
                            <comment id="107120" author="dwight_10gen" created="Thu, 5 Apr 2012 19:55:24 +0000"  >&lt;p&gt;see &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-4328&quot; title=&quot;db level locking&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-4328&quot;&gt;&lt;del&gt;SERVER-4328&lt;/del&gt;&lt;/a&gt; for starters&lt;/p&gt;</comment>
                            <comment id="107109" author="fbjork" created="Thu, 5 Apr 2012 19:29:48 +0000"  >&lt;p&gt;Any progress on adding this?&lt;/p&gt;</comment>
                            <comment id="65444" author="mtucker" created="Tue, 8 Nov 2011 15:50:06 +0000"  >&lt;p&gt;I have also been bitten by using Mongo as a jack of all trades, so +1 for me too.&lt;/p&gt;</comment>
                            <comment id="58011" author="cmercier@websense.com" created="Fri, 30 Sep 2011 21:48:35 +0000"  >&lt;p&gt;+1&lt;/p&gt;</comment>
                            <comment id="52274" author="eliot" created="Fri, 2 Sep 2011 16:19:22 +0000"  >&lt;p&gt;It is still planned.&lt;/p&gt;</comment>
                            <comment id="52252" author="twhitton" created="Fri, 2 Sep 2011 15:13:00 +0000"  >&lt;p&gt;Wondering if this is still planned now that yielding on disk writes has been implemented? We have a lot of use cases where collection level granularity would almost certainly improve performance as we&apos;re currently addressing lock contention through sharding multiple mongod instances on the same server.&lt;/p&gt;</comment>
                            <comment id="37156" author="colinmollenhour" created="Sun, 12 Jun 2011 06:22:26 +0000"  >&lt;p&gt;Was kinda shocked to see that Mongo didn&apos;t already have collection-level locking.. Using a single Mongo as a jack of all trades (app data, logging, job queue, analytics, etc..) maybe isn&apos;t such a great idea at the moment...&lt;/p&gt;</comment>
                            <comment id="34511" author="sandeepmukho" created="Thu, 26 May 2011 07:57:37 +0000"  >&lt;p&gt;Read performance is affected for the same which blocks us to use MongoDB in our production&lt;/p&gt;

&lt;p&gt;Thanks&lt;br/&gt;
Sandy&lt;/p&gt;</comment>
                            <comment id="24221" author="remonvv" created="Fri, 18 Feb 2011 14:56:46 +0000"  >&lt;p&gt;Agreed, &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-2563&quot; title=&quot;When hitting disk, yield lock - phase 1&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-2563&quot;&gt;&lt;del&gt;SERVER-2563&lt;/del&gt;&lt;/a&gt; will remove the high lock contention we&apos;re seeing and is a less specific solution to the problem than collection level locking&lt;/p&gt;</comment>
                            <comment id="23986" author="eliot" created="Wed, 16 Feb 2011 05:23:54 +0000"  >&lt;p&gt;Pushed out in favor of &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-2563&quot; title=&quot;When hitting disk, yield lock - phase 1&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-2563&quot;&gt;&lt;del&gt;SERVER-2563&lt;/del&gt;&lt;/a&gt; which will be more beneficial in more situations.&lt;/p&gt;</comment>
                            <comment id="23939" author="vak" created="Tue, 15 Feb 2011 17:07:32 +0000"  >&lt;p&gt;@Remon, i see.&lt;br/&gt;
however, who knows maybe if the locking would be of record-level, then you would never see your locked ratio reported &quot;100%&quot;?&lt;br/&gt;
maybe even never 1%? &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/wink.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                            <comment id="23938" author="remonvv" created="Tue, 15 Feb 2011 16:36:03 +0000"  >&lt;p&gt;Valery, that&apos;s actually the solution we&apos;re chasing now but it has a lot of serious drawbacks.&lt;/p&gt;

&lt;p&gt;Document level write locks for updates and deletes should be possible but I&apos;d be happy with collection write locks for inserts, updates and deletes.&lt;/p&gt;</comment>
                            <comment id="23931" author="vak" created="Tue, 15 Feb 2011 10:12:31 +0000"  >&lt;p&gt;@Remon, &quot;collection level locking&quot; could be at least resolved in ugly  way &amp;#8211; you create a separate db and server for such a collection. &lt;/p&gt;

&lt;p&gt;What is not solved in any way is a record-level (row-level) locking &amp;#8211; and that becomes pretty unpleasant.&lt;/p&gt;

&lt;p&gt;see closed ticket &lt;a href=&quot;http://jira.mongodb.org/browse/SERVER-1169&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;http://jira.mongodb.org/browse/SERVER-1169&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="23930" author="remonvv" created="Tue, 15 Feb 2011 10:03:49 +0000"  >&lt;p&gt;This is a major issue for us as well. We&apos;re at a point where write lock % is unpractically high in production environments even though writes happen to quite a few different collections.&lt;/p&gt;

&lt;p&gt;Also, where is the JIRA issue concerning durability?&lt;/p&gt;</comment>
                            <comment id="21329" author="eliot" created="Sat, 11 Dec 2010 21:21:38 +0000"  >&lt;p&gt;This interacts with durability too much so need to do in serial.&lt;br/&gt;
Durability will be in 1.8, this in 2.0&lt;/p&gt;</comment>
                            <comment id="21102" author="mediocretes" created="Mon, 6 Dec 2010 17:15:04 +0000"  >&lt;p&gt;We have some collections that are very write heavy and others that are almost all reads - this would be very, very good for us.  We are currently considering a complicated solution that exploits sharding, if this one makes it into 1.8, we won&apos;t have to.&lt;/p&gt;</comment>
                            <comment id="20277" author="eliot" created="Fri, 12 Nov 2010 21:09:46 +0000"  >&lt;p&gt;just a note to check auth is non-blocking when this is done&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                            <outwardlinks description="depends on">
                                        <issuelink>
            <issuekey id="25138">SERVER-4328</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is depended on by">
                                        <issuelink>
            <issuekey id="11381">SERVER-679</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="12158">SERVER-1241</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="14750">SERVER-2563</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                                        </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10220">
                    <name>Tested</name>
                                            <outwardlinks description="tested by">
                                                        </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                <customfield id="customfield_10050" key="com.atlassian.jira.toolkit:comments">
                        <customfieldname># Replies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>45.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Mon, 6 Dec 2010 17:15:04 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        9 years, 48 weeks, 2 days ago
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18254" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Dependencies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[<s><a href='https://jira.mongodb.org/browse/SERVER-4328'>SERVER-4328</a></s>]]></customfieldvalue>


                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                            <customfield id="customfield_10857" key="com.pyxis.greenhopper.jira:gh-epic-link">
                        <customfieldname>Epic Link</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>PM-12</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_10057" key="com.atlassian.jira.toolkit:lastusercommented">
                        <customfieldname>Last comment by Customer</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>true</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10056" key="com.atlassian.jira.toolkit:lastupdaterorcommenter">
                        <customfieldname>Last commenter</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>greg.mckeon@mongodb.com</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11151" key="com.atlassian.jira.toolkit:LastCommentDate">
                        <customfieldname>Last public comment date</customfieldname>
                        <customfieldvalues>
                            9 years, 48 weeks, 2 days ago
                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Old_Backport</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10000"><![CDATA[No]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>ben.brockway@nxtera.com</customfieldvalue>
            <customfieldvalue>chengas123</customfieldvalue>
            <customfieldvalue>cmercier@websense.com</customfieldvalue>
            <customfieldvalue>colinmollenhour</customfieldvalue>
            <customfieldvalue>dwight@mongodb.com</customfieldvalue>
            <customfieldvalue>eliot</customfieldvalue>
            <customfieldvalue>colombiunpride</customfieldvalue>
            <customfieldvalue>fbjork</customfieldvalue>
            <customfieldvalue>fredr313</customfieldvalue>
            <customfieldvalue>geert.pante@persgroep.be</customfieldvalue>
            <customfieldvalue>justanyone</customfieldvalue>
            <customfieldvalue>kradski</customfieldvalue>
            <customfieldvalue>mattparlane</customfieldvalue>
            <customfieldvalue>mcatanzariti</customfieldvalue>
            <customfieldvalue>mtucker</customfieldvalue>
            <customfieldvalue>msalvado</customfieldvalue>
            <customfieldvalue>mediocretes</customfieldvalue>
            <customfieldvalue>lifer</customfieldvalue>
            <customfieldvalue>defcube</customfieldvalue>
            <customfieldvalue>climax</customfieldvalue>
            <customfieldvalue>remonvv</customfieldvalue>
            <customfieldvalue>rogerbinns</customfieldvalue>
            <customfieldvalue>dreammaker</customfieldvalue>
            <customfieldvalue>sandeepmukho</customfieldvalue>
            <customfieldvalue>stephen.steneker@mongodb.com</customfieldvalue>
            <customfieldvalue>rhat</customfieldvalue>
            <customfieldvalue>twhitton</customfieldvalue>
            <customfieldvalue>turneliusz</customfieldvalue>
            <customfieldvalue>happysoft</customfieldvalue>
            <customfieldvalue>vak</customfieldvalue>
            <customfieldvalue>tubededentifrice</customfieldvalue>
            <customfieldvalue>vivekbajpai</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hrpla7:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hrfsxr:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>4857</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_23361" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Requested By</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_10053" key="com.atlassian.jira.ext.charting:timeinstatus">
                        <customfieldname>Time In Status</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_22870" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Triagers</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_14350" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>serverRank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hrllyf:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                    </customfields>
    </item>
</channel>
</rss>