mongo locking

[Liam Staskawicz]

Hello. Can anybody provide an update on the locking situation in
Mongo? http://www.mongodb.org/display/DOCS/Locking+in+Mongo informs
us that it should be included as of Alpha II...?

Also, the current roadmap tantalizes us with the phrase "Enhancements
to durability, concurrency, and locking" in the 1.5 release. Are
there any (rough, even) details that can be shared about what's
planned here? Ideally the locking page above could be updated with
any plans (marked as rough/temporary/subject to change, etc.) Thanks!

Liam

[Geir Magnusson Jr.]

what kind of locking are you looking for?

[Liam Staskawicz]

Mostly wondering if there's any kind of write-locking available (lock
a document, pull it out, modify, save it, unlock), or if this is
something applications need to be designed around. If this is
possible, at what 'resolution'? Per document, per enclosed object,
etc? Also, I couldn't easily find any doc on whether write operations
are atomic?

Of course any general design/philosophical overview thoughts would be
welcome as well.

Liam

[dwight_10gen]

Look for a blog post on locking direction for mongo in the next few
days -- this is something that has been on the todo list, and we are
doing some work right now.

[Liam Staskawicz]

Excellent - looking forward to it. Thanks.

Liam

[Liam Staskawicz]

Hi again - thought I'd follow up on this...short of a blog post, is
there any general background info available on locking in Mongo or
lack thereof? Would be very helpful for evaluation/planning/etc.
Thanks!

Liam

On Mar 31, 2009, at 10:40 AM, dwight_10gen wrote:

>

[Eliot]

I updated this page:  http://www.mongodb.org/display/DOCS/Locking

Its very sparse, but has the very very basics of our concurrent thinking.

If you have any questions, we can try to make that document clearer.

In general, we've been able to find solutions for most problems where transactions would be used in the past.

[Liam Staskawicz]

Great - thanks very much.

Just to be explicit, in the example on the Locking page in the wiki, if db.foo.save(a) succeeds and db.foo.save(b)  or something else in the eval fails/throws an exception afterwards, db.foo.save(a) is not applied or is rolled back?  Or have I misinterpreted 'atomically' here?

Liam

[Eliot]

You've misinterpreted atomic.
Atomic just means that nothing else can happen in between the 2 save operations.

[Michael Dirolf]

afaik it won't roll back - just means nothing else will happen in
between the ops.

[Peter Svensson]

Also, another quick question (Sorry if this have been mentioned before in other threads);
Does this scenario assume that there is only one shard/replica, or do eval marshall (hmm, that would be a lock, I suppose) to other shards.

Cheers,
PS

[Rick R]

Also, on that same subject. With competing records in a sharded installation, can we be assured that the transaction that "wins" does win on every instance? e.g. consistency.

--
We can't solve problems by using the same kind of thinking we used when we created them.
   - A. Einstein

[Eliot]

db.eval and sharding are a bit more complicated, and we haven't worked out all the details of that yet.  We're still making some decisions, so any input would be helpful.  Most likely there will be multiple modes, but again, haven't worked out the details.

Also, on that same subject. With competing records in a sharded installation, can we be assured that the transaction that "wins" does win on every instance? e.g. consistency.

In our sharded model, each shard (partition) only has 1 master at any point.  So there is never a possible cross server race condition.  So everything is always consistent, and yes, last transaction wins.