Closed schristmann closed 7 years ago
Schedulers.io()
is fine as it's just a thread pool. The only way this would trigger is if you potentially leaked a transaction.
Without a sample or something it's going to be impossible to know what's going on.
Sorry I think I jumped the gun on this one. I didn't realize that transactions were stored in a ThreadLocal value. My first pass lead me to think that if Thread A was in the middle of a transaction, that if Thread B started a query it would trigger this exception, but it seems that shouldn't be the case.
You are probably right then that one of the transactions isn't completing somewhere in our code.
Yeah our use of ThreadLocal mirrors the SQLite APIs of Android's use of them as well to track connections.
On Tue, Aug 1, 2017, 1:59 PM Sean Christmann notifications@github.com wrote:
Sorry I think I jumped the gun on this one. I didn't realize that transactions were stored in a ThreadLocal value. My first pass lead me to think that if Thread A was in the middle of a transaction, that if Thread B started a query it would trigger this exception, but it seems that shouldn't be the case.
You are probably right then that one of the transactions isn't completing somewhere in our code.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/square/sqlbrite/issues/208#issuecomment-319448411, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEEEaP1L7G0wLOV-M_yttb7emAS2Q3oks5sT2eDgaJpZM4OpExX .
I'm getting hit with the ensureNotInTransaction exception at random on a simple query that I know is run close to the same time as a lot of web service loading and caching. My best guess is this exception triggers if a web service call happens to be caching data at the same time a query starts, which is a reasonable occurrence anywhere in my app. I have to assume this is because Schedulers.io() works from a thread pool. However the presence of this exception tells me that sqlbrite wants to be single threaded, so is Schedulers.io() really bad to init with? What other guarantee can i use to protect against this exception happening, other then dropping to a single threaded scheduler?