GeezerVison is showing github.com — dbm.sqlite breaks multi-threaded shelve usage · Issue #131918 · python/cpython
dbm.sqlite breaks multi-threaded shelve usage #131918DescriptionBug report
Bug description:
dbm backends were previously thread safe, but I think dbm.sqlite introduced in #114481 is not.
I am not sure if the resolution should be to add a doc comment to shelve/dbm or some other way to fix it, say specifying a preferred backend or multithreading argument in shelve.open as an argument. (Or if there is a way to fix this in dbm.sqlite itself)
Example code:
from concurrent.futures import ThreadPoolExecutor
import shelve
CACHE = shelve.open('test')
def check_set_cache(value):
if 'value' in CACHE:
print(CACHE['value'])
CACHE['value'] = value
return CACHE['value']
jobs = list(range(1, 100))
executor = ThreadPoolExecutor(max_workers=5)
entries = list(executor.map(check_set_cache, jobs))
print(entries)Log
Traceback (most recent call last):
File "/usr/lib64/python3.13/dbm/sqlite3.py", line 79, in _execute
return closing(self._cx.execute(*args, **kwargs))
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
sqlite3.ProgrammingError: SQLite objects created in a thread can only be used in that same thread. The object was created in thread id 140036133836608 and this is thread id 140035884230336.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/megh/pybug/reproduce.py", line 14, in <module>
entries = list(executor.map(check_set_cache, jobs))
File "/usr/lib64/python3.13/concurrent/futures/_base.py", line 619, in result_iterator
yield _result_or_cancel(fs.pop())
~~~~~~~~~~~~~~~~~^^^^^^^^^^
File "/usr/lib64/python3.13/concurrent/futures/_base.py", line 317, in _result_or_cancel
return fut.result(timeout)
~~~~~~~~~~^^^^^^^^^
File "/usr/lib64/python3.13/concurrent/futures/_base.py", line 449, in result
return self.__get_result()
~~~~~~~~~~~~~~~~~^^
File "/usr/lib64/python3.13/concurrent/futures/_base.py", line 401, in __get_result
raise self._exception
File "/usr/lib64/python3.13/concurrent/futures/thread.py", line 59, in run
result = self.fn(*self.args, **self.kwargs)
File "/home/megh/pybug/reproduce.py", line 7, in check_set_cache
if 'value' in CACHE:
^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.13/shelve.py", line 102, in __contains__
return key.encode(self.keyencoding) in self.dict
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<frozen _collections_abc>", line 817, in __contains__
File "/usr/lib64/python3.13/dbm/sqlite3.py", line 89, in __getitem__
with self._execute(LOOKUP_KEY, (key,)) as cu:
~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.13/dbm/sqlite3.py", line 81, in _execute
raise error(str(exc))
dbm.sqlite3.error: SQLite objects created in a thread can only be used in that same thread. The object was created in thread id 140036133836608 and this is thread id 140035884230336.
(Observed here beancount/beanprice#91 )
CPython versions tested on:
3.13
Operating systems tested on:
Linux
Linked PRs
Activityadded 2 commits that reference this issue on Mar 30, 2025This issue will close once commit 3818ab7 is merged into the 'main' branch.3818ab7 This issue will close once commit bbbdbc3 is merged into the 'main' branch.bbbdbc3 brianschubert commented on Mar 30, 2025
dbm backends were previously thread safe
Is this actually promised anywhere? I don't see any mention of thread safety in the current docs. Some language should probably be added to explain what sort of thread-safety guarantees users can expect (if any?) Reacted by Erlend E. Aasland, Serhiy Storchaka and Furkan Onder serhiy-storchaka commented on Jul 6, 2025 It does not look to me that dbm.dumb was thread-safe. guillaume-fr commented on Oct 28, 2026
SQLite objects created in a thread can only be used in that same thread.
@brianschubert , isn't it even more strict than not being thread-safe?
I agree relying on undocumented thread-safety can be UB. Now, with no specific documentation, I'd expect objects to support thread agility : being used from different threads, as long as it's properly locked. Isn't introducing such specific single-thread restriction, on the default provider, a breaking change?
MetadataMetadataStatusShow more project fields StatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|