Static DB pool using tokio::sync::OnceCell

[tayleighr]

Summary

First, thanks to the maintainers for the detailed documentation and examples. This question is born out of curiosity rather than any issue I'm having sharing the database pool in the way prescribed in the documentation (via state extractor).

I'm working in a rust mono-repo and have configured other projects in the repo to reference a static ref to a sqlx pg pool (sea_orm) using tokio::sync::OnceCell.

The motivation for extending this pattern for my axum project would be pretty minor -- to access the pool in a consistent way with respect to other projects in the mono-repo.

It's my understanding that axum serves all concurrent connections from a single runtime, so I believe every handler should be able to reference the static db pool from a common configuration module without the need to define the state extractor in the handler arguments.

In the end it seems like I'm sharing a reference across my active connections either way. Am I missing anything?

Thanks in advance

axum version

0.7.4

[jplatte]

I think you're misunderstanding a few things, but your conclusion is correct.

First off, both axum and tokio's OnceCell type don't interact with the tokio runtime at all, i.e. they can be used inside any async runtime (axum::serve does make use of hyper-utils tokio integration, but you serve connections and pass them to axum differently). So even if the runtime that runs the async closure to initialize the cell was different from the one that you use to run hyper/axum in, that wouldn't be a problem.

To your actual question, there is nothing inherently wrong with sharing state with statics instead of axum's State. We recommend State because it's easy and has the advantage of allowing multiple routers with independent state within one program, such as an integration test binary where each test sets up its own app state and router.

[tayleighr]

Thanks @jplatte. That answers my question.

As to the reference to the runtime. I was under the impression that the underlying TCP connections held by the pool are runtime bound, which would make it important for the connections to be served from a single runtime.

I've run into trouble before implementing tests that each reference my static db pool (set up as described).

At the time I concluded that the issue was that the tests were being spun up on separate runtimes, and while that was not an issue with the OnceCell itself, it did cause undefined behavior as underlying tcp connections would be terminated once the associated runtime ended at the conclusion of a given tokio::test (I used the documentation of this crate to come to this conclusion: https://docs.rs/tokio-shared-rt/latest/tokio_shared_rt/).

Happy for a learning moment if this conclusion seems incorrect, but I'm sure you're a busy person so no worries either way.

[jplatte]

As to the reference to the runtime. I was under the impression that the underlying TCP connections held by the pool are runtime bound, which would make it important for the connections to be served from a single runtime.

Ah yes, this might be true. I was not considering the specifics of SQLx and just talking about the general mechanics of statics vs axum::extract::State. That would be a good reason for you to use State for the pool then and set up one pool per test, to avoid that problem :)