Issue #332 shows an example of a deadlock caused by calling set_session_field from within a sql callback, in an application using SQLite and sql_sessions.
The deadlock was explained as being caused by sql_sessions using sql inside set_session_field, resulting in a nested call to sql. The SQLite driver supports one single connection, so a nested call immediately triggers a deadlock.
In that particular case, the op was able to rework the code to avoid the nesting.
Also, Dream now detects the nesting and issues a warning.
My interpretation is that the author considers this a corner case tied to using a particular implementation (SQLite) that doesn't support concurrency, and a particular pattern of using set_session_field within a sql callback.
I think the problem is more severe, and shows a flaw in the design of sql_pool.
There are two main points.
-
Nesting calls to sql is never safe. Even with backends that support parallelism, you can deadlock if you have N connections doing a nested sql call on a pool of size N.
-
Nesting calls to sql is inevitable, as soon as you need the database inside a middleware, e.g., sql_sessions.
Hence my question: is using sql together with e.g., sql_sessions safe? And more in general, how can one use sql both in a middleware and in a final handler, or in two sequential middlewares?
Issue #332 shows an example of a deadlock caused by calling
set_session_fieldfrom within asqlcallback, in an application using SQLite andsql_sessions.The deadlock was explained as being caused by
sql_sessionsusingsqlinsideset_session_field, resulting in a nested call tosql. The SQLite driver supports one single connection, so a nested call immediately triggers a deadlock.In that particular case, the op was able to rework the code to avoid the nesting.
Also, Dream now detects the nesting and issues a warning.
My interpretation is that the author considers this a corner case tied to using a particular implementation (SQLite) that doesn't support concurrency, and a particular pattern of using
set_session_fieldwithin asqlcallback.I think the problem is more severe, and shows a flaw in the design of
sql_pool.There are two main points.
Nesting calls to
sqlis never safe. Even with backends that support parallelism, you can deadlock if you have N connections doing a nestedsqlcall on a pool of size N.Nesting calls to
sqlis inevitable, as soon as you need the database inside a middleware, e.g.,sql_sessions.Hence my question: is using
sqltogether with e.g.,sql_sessionssafe? And more in general, how can one usesqlboth in a middleware and in a final handler, or in two sequential middlewares?