Multiple ctx created from context.Background()

[lobre]

Hey,

I'd like to ask what is your way to go for interacting with context.

I had in mind that it was a good idea to have a ctx created from context.Background() in the early stages of the bootstrap process of the application (let's say in the main.go of a cmd package), and then passed around from there to other packages.

But it seems you don't necessarily follow this pattern. For instance, you instantiate another context from context.Background() directly in the sqlite package. What has driven this choice? Why that instead of accepting a context from the NewDB "constructor"?

If something unfortunate happens in the main package (or if the user interrupts), you call db.Close() and cancel the inner context from within that method in the sqlite package. Is it to have a clearer boundary between main and sqlite package?

Thanks a lot for the clarification.
Loric

[benbjohnson]

Good question. The context is typically request-based so it's generated from the HTTP server and that's what's used for most of the code in wtf. Typically the exception is background processing like what the sqlite.DB.monitor() function is doing.

The reason I like to manage an internal context for DB instead of using one from main() is that it lets me control the shutdown process better. For example, I typically want to wait for the signal from the OS to shutdown and then shutdown the HTTP server and then shutdown the DB. That allows me to gracefully close open connections on the HTTP server whereas closing the DB first would immediately return errors on open connections.

If you pass a cancelable context from main() to both the DB & HTTP server then you don't have any control over which one will close first.

[lobre]

Makes sense! Thanks for taking the time to answer.

[lobre]

In fact, after having spent more time analyzing sqlite.go, I have another quick question.

You said context was typically request-based. So every action/process that is triggered from the HTTP server will get the HTTP request context which totally makes sense to me. They depend on the lifecycle of that request.

Having said that, all the setup of the SQLite DB in main.go happens before the HTTP server is even created. So I understand better the use of this second context injected from context.Background() directly in the sqlite.DB. Effectively, this setup does belong to a prior "step" in the lifecycle of the application and so cancellation should also be possible at this stage using this sqlite.DB.ctx (for instance if the os sends the exit signal before the HTTP server is even created). Correct me if I am wrong but I think I get this part now :-).

However, I have another small related question. As you said, this sqlite.DB.ctx is used in the background process sqlite.DB.monitor(). But while it is available and ready, why don't you use it in other methods that also belong to this "setup stage" of the DB? I am talking about the following ones.

func (db *DB) Open() (err error)
func (db *DB) migrate() error
func (db *DB) migrateFile(name string) error

I can see they don't use sqlite.DB.BeginTx. They create their own transactions and they execute SQL queries using regular Exec instead of the context-based ExecContext.

My take on answering that is that they execute relatively rapidly and only when the application is started. So they might not need the overhead of a context. Am I guessing right?

Thanks a lot.

[benbjohnson]

But while it is available and ready, why don't you use it in other methods that also belong to this "setup stage" of the DB?

The Open() method is called before the Close() method (which is what calls cancel()) so it doesn't make sense to use the DB.ctx there. You could pass in a context.Context to Open() and use that if you think your setup could take a while and you want to cancel it.