Question

I am working on a page hierarchy (mongodb document):

{
    _id: 012,
    content: "lorem ipsum whatever...",
    subpages: [123,234,345,456], // page ids
}

The page structure will actually be highly dynamic, so many updates will occur simultaneously with many reads. However, every change (like moving a subpage into another page) requires at least 2 update operations:

// move 123 into page 234
db.pages.update({"_id":012}, {$pull:{"subpages":123}});
db.pages.update({"_id":234}, {$push:{"subpages":123}});

// delete page 345
db.pages.update({"_id":012}, {$pull:{"subpages":345}});
db.pages.remove({"_id":345});

Is there a way to perform (or design the model to enable performing) operations like moving a page or deleting a page atomically (to prevent the state of the hierarchy going bad)?

Notes

One possibility I’m looking at right now is manually locking the documents by adding a “lockedBy” field to every page, which will contain a transaction ID. But I don’t like the idea of continuously polling if I want a second locking operation to block until the first locking operation completes (see https://jira.mongodb.org/browse/SERVER-2244). Also, since locking is managed by the application, if the application (or one instance of it) goes down for whatever reason during a locking operation, the documents need to be unlocked somehow, without affecting other transactions.

I’ve also looked at http://www.mongodb.org/display/DOCS/Trees+in+MongoDB and it seems that none of the examples (except for the single document one) solves this problem. However, I would like to avoid putting the entire hierarchy into a single document, because of the 16MB document size constraint and the difficulty of moving pages around (basically I need to upsert the entire document for every change).

Updates

We hope to support up to 10000 subpages for a page. The IDs for pages are at least 6 characters long. With that in mind, we moved from mySQL because we need to keep track of the order of the sub-pages. Since mySQL doesn’t have array structures, the only way to do that is to use a position column. When pages are moved around frequently, it is expensive to calculate average positions and re-index when the position value becomes too long. Also, if we wanted to put a comma separated list of ids into a column, we would have to use a TEXT column (read from disk) rather than a VARCHAR (which has a limit of 65536 chars) in order to support 10000 sub-pages.

Answer 1

There are no transactions. There are atomic operations but they only operate on one document at a time. I’d say, your only choice for a reliable update is to put the whole hierarchy into one document. I wouldn’t worry too much about running over document limit: 16MB is a LOT of integers.

Also I think, this is an example where a “regular” relational transactional database is much more useful.