ObjectBox version 2.7.1, MaxNumReaders 500, @Entity count over 50, Some entities has over 100K rows. Two weeks after release, we started getting errors in Sentry: Could not begin read transaction (maximum of read transactions reached) How to diagnose a problem at an early stage with a debugger?
1 Answers
When you hit a DbMaxReadersExceededException, you can typically resolve the issue by check these options:
Because you already increased the max readers value, I assume you use multiple threads. The first thing I'd do is to verify your threading logic. We've seen cases where apps spawned threads without limits and thus breaking readers. Each thread requires a reader when accessing ObjectBox DB. Thus, getting a DbMaxReadersExceededException may be a symptom of a problem in your threading code.
If you have a lot of short-lived threads, you may see logs like "W/Box: Skipping low-level close for read-only cursor (non-creator thread)" or "Hint: use closeThreadResources() to avoid finalizing recycled transactions". The latter hint is exactly what you should do before your thread exits. If you used only one or two
Box
es, you can call the method on the box:box.closeThreadResources()
, otherwise the BoxStore also offers a method with the same name to do this for all Boxes.There's also currently an open issue related to unbound thread pools. If you run into that, the current workaround is to use thread pools with an upper limit.

- 6,950
- 31
- 52
-
We use multiple threads. If we call boxStore.diagnose() we see some readers count. And we have this log I/System.out: Hint: use closeThreadResources() to avoid finalizing recycled transactions (initial commit count: 69). W/Box: Skipping low-level close for read-only cursor (non-creator thread '') W/Box: Destroyed recycled transaction from non-owner thread '' – DimitriyPav Jul 28 '21 at 17:58
-
I added a section on short-lived threads to the answer. Hope that helps you! – Markus Junginger Jul 29 '21 at 11:03