DatabaseError: DatabaseWrapper objects created in a thread can only be used in that same thread.

[Brian May]

Traceback (most recent call last):
  File "/usr/lib/python2.7/wsgiref/handlers.py", line 85, in run
    self.result = application(self.environ, self.start_response)
  File "/usr/lib/python2.7/dist-packages/django/contrib/staticfiles/handlers.py", line 64, in __call__
    return super(StaticFilesHandler, self).__call__(environ, start_response)
  File "/usr/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 177, in __call__
    signals.request_started.send(sender=self.__class__, environ=environ)
  File "/usr/lib/python2.7/dist-packages/django/dispatch/dispatcher.py", line 201, in send
    response = receiver(signal=self, sender=sender, **named)
  File "/usr/lib/python2.7/dist-packages/django/db/__init__.py", line 64, in close_old_connections
    conn.close_if_unusable_or_obsolete()
  File "/usr/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 403, in close_if_unusable_or_obsolete
    self.close()
  File "/usr/lib/python2.7/dist-packages/django/db/backends/sqlite3/base.py", line 221, in close
    self.validate_thread_sharing()
  File "/usr/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 421, in validate_thread_sharing
    % (self.alias, self._thread_ident, thread.get_ident()))
DatabaseError: DatabaseWrapper objects created in a thread can only be used in that same thread. The object with alias 'default' was created in thread id 140201111500544 and this is thread id 140201088387984.

Using instructions found in Debian bug report:
​https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804340

This looks like a database issue to me, however the reporter of the Debian bug thinks it is something to do with the capital-letter-named django application. Which seems weird to me.

A search for similar bugs found #17998 - not idea if this is related or not.

[Brian May]

Forgot to clarify - The Debian bug report is against Django 1.7.7, however I reproduced the above with Django 1.8.4

[Aymeric Augustin]

I can't tell from the original report which database the person is using as the PostgreSQL, MySQL and SQLite adapters are installed. Django allows sharing SQLite connections across threads but not PostgreSQL and MySQL connections.

Generally speaking database connections should only be accessed through from django.db import connection or from django.db import connections; connections[alias]. This returns thread local objects and avoids this problem.

The TinycryptoPOS application appears to run a daemon; I'm not sure what it does exactly but I suspect that's how a connection ends up being accessed incorrectly. If every Django user saw that error, we'd probably have heard about it by now, so I suspect the bug is in TinycryptoPOS.

[Aymeric Augustin]

Closing the Debian bug and forwarding here was the right thing to do. The discussion about single-core / multi-core is irrelevant -- of course you can't reproduce an issue that's obviously related to threads when running single-threaded.

[Brian May]

From the Debian bug report:

I found the origin of the problem: It was the pyjsonrpc library that is included into TinycryptoPOS. After I commented out every part of code that uses something from pyjsonrpc the error disappeared.

You just have to import pyjsonrpc in your Django application without using code from it and the error appears... but only on amd64. I have verified this with another Django application.

I think this is clearly a bug in pyjsonrpc and not a django bug.

Thank you for your help and time and also thanks to the people on the django mailing list for giving me the hint to the right direction.

I have looked at pyjsonrpc (download from PyPI, link to github project is dead), I am not convinced it could cause this problem. However it uses things like gevent and WebSocketClient from ws4py.client.geventclient - both of which I haven't used myself, so I might be mistaken.

[Tim Graham]

If this is a Django problem, I think you'll need to propose a fix or at least provide the reasoning why.