So while reading the page on wtimeout I found this paragraph, where the first line seem to disagrees with the second line.
wtimeout causes write operations to return with an error after the specified limit, even if the required write concern will eventually succeed. When these write operations return, MongoDB does not undo successful data modifications performed before the write concern exceeded the wtimeout time limit.
So, the driver will throw an error if wtimeout is exceeded, however the write will potentially still happen.
The next line says the MongoDB doesn’t undo a successful data modification before the wtimeout time limit is exceeded, which implies that it does if it is exceeded??
Cheers. I appreciate that I have read it incorrectly.
If the Wtimeout exceed the write might succeed , retrayble writes could help in some secnarios .
However a Wtimeout is something application logic should address , potentially with unique indexes data Will fail reinserting or with update/upsert logic the action can be redone…
If we use the premise of catching the wtimeout issue in the appplication code, and retrying with an upsert using a unique key.
The problem that caused the wtimeout, may still be prevalant, at which point we may have written the data, or may not, but because the application doesn’t know even after a retry.
The application, can report to the user, that things are not working (Please try again later), but we have this piece of data which is potentially incomplete, from a processing point of view.
How would one manage this orphan data? Just accept, it is incomplete, and move on? Coding around the issue of incomplete data?
From my previous background, the process would have been one complete transaction, committed in it’s entirety at the end of the process (Depending on size of the transaction of course), using a before image if we had to roll back.
@NeilM I have a similar question, what happens to the replicas to which data is not written by the time a timeout occurs, can it still be written after the timeout? Have you found an answer to this?
Due to the nature of network, even if you receive a timeout error, it simply means the the servers fail to respond within that time and nothing else. The writes may or may not succeed at that time, and may eventually succeed.
The application will not know that unless some certain conditions are met (e.g. unique index in place).
To make sure all happen or nothing happens, you have to use a transaction. With transaction semantics, once you get an abort error, you know the changes will be eventually rolled back, and if you successfully commit it, you know the changes will be eventually there.