First, make a list of several levels of writeconcern that throw exceptions: Writeconcern.none: No exceptions thrown writeconcern.normal: Only network error exceptions are thrown, no server error exception is available Writeconcern.safe : Throws a network error exception, a server error exception, and waits for the server to complete the write operation. Writeconcern.majority: Throws a network error exception, a server error exception, and waits for a primary server to complete the write operation. Writeconcern.fsync_safe: Throws network error exception, server error exception, write operation waits for server to flush data to disk. Writeconcern.journal_safe: Throws a network error exception, a server error exception, and a log file that the write operation waits for the server to commit to the disk. Writeconcern.replicas_safe: Throws a network error exception, a server error exception, and waits for at least 2 servers to complete the write operation.
When we do the following (set the age of "name" to "Lily" to 20):
Db.update ({"Name": "Lily"},{"$set": {"Age": 20}})
By default, this action uses Writeconcern.normal, which throws an exception only when a network error occurs, and is equivalent to:
Db.update ({"Name": "Lily"},{"$set": {"age": 20}},writeconcern.normal)
Using the normal mode parameter can make the write operation very efficient. However, if the server fails at this time, it will not return an error to the client, and the client will mistakenly believe that the operation was successful.
Therefore, it is necessary to use the Writeconcern.safe mode in many important write operations to ensure that the client and the server are consistent in understanding the correctness of the operation.
(according to the author test, if the server occurs, the client still does not get the error of the operation back, need special attention)
In addition, in many cases, we need to know exactly whether the write operation was successful (or how many objects the update operation affected), and this time we need to:
Writeresult ret = db.update ({"Name": "Lily"},{"$set": {"Age":}});
if (RET.GETN () >0)//operation affects the number of objects return
true;
else return
false;
Or:
Writeresult ret = db.update ({"Name": "Lily"},{"$set": {"Age":}});
if (ret.getlasterror () = null) return
true;
else return
false;
At this point, GetLastError () queries the results of the last operation to see if an error occurred.
Further
Then because of the reason for using the connection pool in MongoDB, GetLastError () needs to get the connection again from the connection pool, which is more efficient. You can do this:
Db.requeststart ();
Writeresult ret = db.update ({"Name": "Lily"},{"$set": {"Age":}});
if (ret.getlasterror () = null) return
true;
else return
false;
Db.requestdone ();
You can guarantee that the update operation and GetLastError () use the same connection and reduce the process of a single save/fetch connection.
There's another way.
You can also use the Writeconcern.safe parameter at this time:
Writeresult ret = db.update ({"Name": "Lily"},{"$set": {"Age":}}, Writeconcern.safe);
if (ret.getlasterror () = null) return
true;
else return
false;
is equivalent to
db.requeststart ();
Writeresult ret = db.update ({"Name": "Lily"},{"$set": {"Age":}});
if (ret.getlasterror () = null) return
true;
else return
false;
Db.requestdone ();
This is also the way I recommend it, so that you can efficiently get the results back, but also feel the server error, kill two birds with one stone.