[Bug 856004] [NEW] "OperationalError: database is locked" encountered under very light load while using REST API

[Barry Warsaw]

On Sep 22, 2011, at 12:17 AM, Stephen A. Goss wrote:

>I've seen this error twice while running integration tests (of our own
>application) that access Mailman 3 using the API. The load on Mailman is
>very light, as all requests made to the API are serial, never in
>parallel. Of course the various processing queues in MM3 are separate
>processes and could be doing work concurrently.

This probably means that one of the other processes is holding onto the
database lock longer than it should, e.g. by not committing or aborting the
transaction.  I believe Python's sqlite layer should retry the transaction for
a few seconds when it finds the database is locked.  We'll have to hunt down
which other process is holding the database lock (and add some debugging
instrumentation if necessary).  Fortunately, we don't have threads to worry
about!

>The backend here is SQLite, which falls over very quickly under
>concurrent load. If the goal here is to create a stable mailing list
>server, maybe SQLite is a poor default.

It could be that sqlite is only really useful for the test suite.  However,
Storm (our ORM layer) supports MySQL and PostgreSQL.  Have you tried either of
those databases?

-- 
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/856004

Title:
  "OperationalError: database is locked" encountered under very light
  load while using REST API

To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/856004/+subscriptions