OP in PHPC-1523 reported that an application performing many findAndModify commands on large documents can quickly populate its oplog when retryable writes are enabled (as is the case by default since driver's 4.2-compat releases).
The drivers retryable writes specification has historically only permitted the feature to be configured at the MongoClient level in order to limit the API changes (vs. granular configuration on a database, collection, or per-operation). Therefore, it's difficult for applications to work around this and disable retryable writes just for findAndModify operations without off-loading all of those operations to a dedicated MongoClient.
That said, the side effect of findAndModify with retryable writes is not very intuitive. Given that retryable writes is advertised as a "set it and forget it" feature, I don't think most users would even consider this side effect if they were not watching their oplog activity (as was the case in PHPC-1523). As for documentation, I suppose we could note this in either the retryable writes or findAndModify docs (or both), but it does seem very specific and could easily be missed.
In a linked HELP ticket, schwerin mentioned that "our current implementation of retryable writes isn't the only viable one", so I'm opening this SERVER ticket to start a discussion on how we could alleviate this side effect for users without requiring them to change their applications or disable retryable writes altogether.
- is related to
-
PHPC-1523 findAndModify generates 50-100x more oplog traffic with retryWrites=true
- Closed
- related to
-
SERVER-45653 avoid writing unneeded fields to no-op oplog entry to findAndModify with retryable writes
- Closed