What operation ordering guarantees are there without durability (mongo)?

Question

Suppose you have an ACID database. Without an explicit guarantee about operation ordering, you can still infer ordering as a result of durability.

e.g.

1. I insert x into a database and the statement returns
2. Now I insert y
3. because of a Durability guarantee, I know x was made durable before y.

Thus, in event of a crash, I either have:

1. none of x or y in the database
2. only x
3. both x and y.

Now assume a database with a relaxed durability guarantee. e.g. MongoDB without safemode or getlasterror.

What guarantee do I have that the first operation is made durable before the second operation is made durable?
Please point me to the part of documentation that claims this, or the appropriate test.
In event of failure can my database contain y but not x?

EDIT:
It seems the default (only?) storage mechanism is memory-mapped files engine. Without journaling enabled (now enabled by default), it seems a server crash can result in an inconsistent and irreparable state. I guess the answer lies within the journaling.

Answer 1

To answer my own question:

There is a guarantee with journaling. Specifically, the journals are write-ahead redo logs.

With journaling enabled, journal files will be created in a journal/ subdirectory under your chosen db path. These files are write-ahead redo logs. In addition, a last sequence number file, journal/lsn, will be created. A clean shutdown removes all files under journal/.

Source: http://www.mongodb.org/display/DOCS/Journaling#Journaling-JournalFiles

There is no guarantee (I can find or comprehend) without journaling. MongoDB uses memory-mapped files as it's primary storage engine. Writes to memory are not immediately reflected in the filesystem. In the case of an OS crash (for example), the files might be in an inconsistent and unrecoverable state.

Answer 2

Depending on your use case, you can use Mongo's Capped Collections that maintain insertion order for the objects in the collection. With some restrictions though, check the docs.

You can also get more insight from Sorting and Natural Ordering:

For standard tables, natural order is not particularly useful because, although the order is often close to insertion order, it is not guaranteed to be. However, for Capped Collections, natural order is guaranteed to be the insertion order.