Details
-
Improvement
-
Resolution: Unresolved
-
Major - P3
-
None
-
None
-
None
-
None
Description
Currently we have documented for mongoc_client_set_read_concern:
It is a programming error to call this function on a client from a mongoc_client_pool_t. For pooled clients, set the read concern with the MongoDB URI instead.
I believe the reason it is considered a programming error is that it persists on the mongoc_client_t even after being pushed back onto the pool. For example:
pool = mongoc_client_pool_new (uri);
|
client = mongoc_client_pool_pop (pool);
|
rc = mongoc_read_concern_new ();
|
mongoc_read_concern_set_level (rc, MONGOC_READ_CONCERN_LEVEL_AVAILABLE);
|
mongoc_client_set_read_concern (client, rc);
|
mongoc_client_pool_push (pool, client);
|
client = mongoc_client_pool_pop (pool);
|
level = mongoc_read_concern_get_level (mongoc_client_get_read_concern (client));
|
printf ("rc=%s\n", level); /* prints "rc=available" */
|
mongoc_read_concern_destroy (rc);
|
This behavior seems surprising and error prone. I think the same applies to write concern and read preference. I think it would be simple enough to have mongoc_client_pool_push reset its state (clear the read/write concern and read preference) before being pushed back onto a pool.
Attachments
Issue Links
- is depended on by
-
CXX-1939 Revisit deprecation of client read_concern, write_concern, and read_preference methods
-
- Backlog
-
- is duplicated by
-
CDRIVER-3878 reset client options when returning to a mongoc_client_pool
-
- Closed
-
- is related to
-
CDRIVER-938 Prohibit setting options on pooled clients
-
- Backlog
-