clsql-fluid
CLSQL-Fluid is a backend for CLSQL that provides trivial SQL database connection thread-safety for most applications. It solves the problem of client code and DB-backed objects sharing a connection across threads, while still allowing that code and those objects to be thread-agnostic.

It was written to make the CLSQL backend to cl-Weblocks thread-safe, but should be useful for other applications employing database access and threads.

Porting code is almost always trivial; just instantiate fluid-database instead of calling connect.

While it is provided as a separate library, the preferred form of using it is to merge its Git branch.

More information is available on the common-lisp.net project page.

Someone, probably the CLSQL maintainer, added this comment:

Note: CLSQL-Fluid is a hack for cl-weblocks because the latter uses CLSQL incorrectly. CLSQL supports multithreading without any problems using the WITH-DATABASE macro. See the following web pages for more info:

http://lists.kpe.io/pipermail/clsql-help/2005-April/000416.html

http://clsql.kpe.io/manual/with-database.html

Here is a counterargument. In a Web server, using CLSQL correctly, by this definition, is not easy. It is tempting to think that you can call WITH-DATABASE once in each thread, and that will suffice, but the problem is that there are (normally) database-backed objects whose lifetimes are longer than a single request. This means they can be created in one thread, handling one request, and then used in a different thread, handling a subsequent request. Also, each database object remembers the database connection by which it was created; it has to, in order to implement join slots. The upshot is, if you access a join slot of an object created in a different thread, it can try to access the same connection as the one being used in its original thread, at the same time the original thread is using it, which doesn't work.

The "correct" fix, by the above argument, would be to associate a database connection with each server session, since objects are not shared across sessions. But this is wasteful; a busy server could have hundreds or thousands of active sessions at any given moment. CLSQL-Fluid, by contrast, creates only one connection per server thread; there are generally not more than a few dozen threads. For this reason, I am using CLSQL-Fluid in my Weblocks-based site, and recommend it to others. -- Scott L. Burson