[JAVA-688] Java driver concurrency documentation should state that db.requestStart() will not guarantee reading own writes with slaveOk if sharding Created: 01/Nov/12 Updated: 13/Nov/14 Resolved: 13/Nov/14 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Documentation |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Ian Daniel | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | |||
| Issue Links: |
|
||||||||
| Description |
|
The Java Driver Concurrency documentation documents the use of db.requestStart() and db.requestDone() to try to ensure that you read your own write when slaveOk is set. However, it should indicate that this technique is only effective if you are not sharding, and hence the driver is connecting directly to the mongod instances. When you are sharding, while requests will be processed sequentially by the mongos, there is no guarantee that writes and reads will be directed to the same underlying mongod. Hence you should never use slaveOk in a sharded environment if consistency across requests is important. This documentation should also mention that slaveOk is deprecated, and instead (or also) refer to read preferences rather than slaveOk. Perhaps some of the other driver documentation has the same issues. I did not check. |
| Comments |
| Comment by Jeffrey Yemin [ 13/Nov/14 ] |
|
I also opened a pull request to remove reference to DB.requestStart from the concurrency page in the tutorial. |
| Comment by Jeffrey Yemin [ 13/Nov/14 ] |
|
These methods are deprecated in 2.13 and will be removed in 3.0. |
| Comment by Jeffrey Yemin [ 12/Jul/13 ] |
|
This can be more succinctly stated as DB.requestStart does not provide monotonicity. Read preference is obeyed, even after a write. |
| Comment by Scott Hernandez (Inactive) [ 02/Nov/12 ] |
|
This statement is true in general, " you should never use slaveOk in a (sharded environment) if consistency across requests is important "; you can remove the "sharded environment" part and it is still true. You need to ensure that the write is safe/w=all, and read only from the primary for this kind of consistency. |
| Comment by Scott Hernandez (Inactive) [ 02/Nov/12 ] |
|
We can produce a simple test using the shell to prove this. If we start a replica set with 3 members (1 with a slaveDelay of 5 minutes to simulate noticeable replication lag) and put it behind mongos and set slaveOk then queries will go to the closest secondary (or split between them). If the only secondary left after shutting down the other one is the slaveDelay'd node then queries will go to it, and all reads will be 5 minutes behind writes (at best), even if you use requestStart/End (since mongos deals with doling out requests). |