[SERVER-1241] Document-level locking Created: 15/Jun/10 Updated: 27/Oct/15 Resolved: 05/Nov/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency |
| Affects Version/s: | None |
| Fix Version/s: | 2.8.0-rc0 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Eliot Horowitz (Inactive) | Assignee: | Eliot Horowitz (Inactive) |
| Resolution: | Done | Votes: | 95 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Document Level Locking is now available with the wired tiger storage engine. |
| Comments |
| Comment by Roman Sh [ 22/Oct/14 ] |
|
Can anyone explain when MongoDB has the document-level locking will it touch both write and read operations? I mean if we write it locks for reading only the document we write? |
| Comment by Asya Kamsky [ 19/Sep/14 ] |
|
It's been said that this feature is targeted for 2.8 release later this year. However, unless you've actually tried your use case and seen the lock be an issue, it's quite unlikely that it will be the limiting factor - it's not for most use cases out there and it's very possible to get tens of thousands of writes/second in the current version. |
| Comment by Eric Franckx [ 18/Sep/14 ] |
|
yep, a lot of people are waiting the 2.8 that will come with document-level locking ... |
| Comment by Nomane [X] [ 18/Sep/14 ] |
|
Hi Guys, I m a try to start a new project and I would like to use Mongo as it seems to be suitable for my application (especially for geo-spatial search) but the write lock issue at database level is clearly a no go and I think that a lot of people leave Mongo for this same reason ... Have you plan to resolve this issue soon ? If yes for which release and with how many percentage of confidence ? Thanks Nomane Oulali |
| Comment by Arunoda Susiripala [ 02/Aug/14 ] |
|
Ah okay. Thanks. |
| Comment by Asya Kamsky [ 01/Aug/14 ] |
|
arunoda.susiripala@gmail.com I'm not sure what the "this" you are referring to is. There is no release of this branch scheduled for today/yesterday - 2.7.5 is scheduled for later this month , but that's just a milestone in 2.7 development branch. |
| Comment by Arunoda Susiripala [ 01/Aug/14 ] |
|
Guys, this is scheduled to release today. Is that gonna happen? I'm looking so badly to try out document level locking. |
| Comment by Roman Sh [ 10/Jun/14 ] |
|
Kevin, thank you for explaining! That's good. The same behavior is at this moment? I am asking that because when I run a long multiple update query with big collections I get my applications freezing. so I thought that the database was locking all the time of an update query. |
| Comment by Kevin J. Rice [ 10/Jun/14 ] |
|
Mongo does not, and probably won't ever, support transactions. Thus, the simple answer to multi:true situations is to iterate through found records, and (lock, update, unlock) each of them in order. No worries. |
| Comment by Roman Sh [ 10/Jun/14 ] |
|
Imagine, we make an update with multi:true. What happens in the case in context of document-level locking? Do we have locking of all the documents all the time when that query executes or locking affects the documents one by one? |
| Comment by Flavien [ 15/Aug/13 ] |
|
Would it be possible to have document level locking? At least in the case of an in-place update that doesn't require relocating the document. |
| Comment by Eliot Horowitz (Inactive) [ 22/Feb/11 ] |
|
@valery, we try not to schedule things until we're confident we are going to get it right, and we have a number of tasks for concurrency this year, still figuring out the exact order Not sure what you're issue is, but take a look at |
| Comment by Valery Khamenya [ 22/Feb/11 ] |
|
guys, could you schedule this ticket, please? This ticket still remains very important for us. |