Multithreaded access to DB handle panics about mongo-rust-driver HOT 3 CLOSED

Thanks @patrickfreed for the feedback!

I'll see if I can figure out how to do the latter (single runtime for multithreaded tests), since that more closely resembles the webapp experience.

Really what I'm looking for is a way to access a static pool of connections in a multithreaded environment, without the overhead of reestablishing a connection each time I need one.

Re: a few other notes:

• Good to know. I'll do away with the wrapping Arc
• The purpose is along the lines of a singleton connection instance... trying to accomplish a shared connection (or pool) as mentioned.

Thanks again!

from mongo-rust-driver.

Each #[tokio::test] spins up its own runtime, so it's not possible to share the same client from each of them. Instead, I'd recommend creating a new client in each test. Alternatively, you can create a single runtime outside of the tests that is shared by each test, and annotate them with the regular #[test] instead.

A few other notes:
- Collection internally is just a wrapper around an Arc and is Clone, so you don't need to wrap it in an Arc
- It's not clear to me what the expected behavior of using futures::block_on in a static context is with the driver. I'd recommend instead awaiting the futures from within the context of a tokio runtime instead.

from mongo-rust-driver.

No problem, happy to help. Also, the Client type internally manages connection pools to each server in the deployment, so sharing one will indeed achieve the pooling behavior you're looking for (no need to pool the clients).

Going to go ahead and close this ticket, but please let us know if you have any further questions!

from mongo-rust-driver.