square / sqlbrite

A lightweight wrapper around SQLiteOpenHelper which introduces reactive stream semantics to SQL operations.
https://square.github.io/sqlbrite/3.x/sqlbrite/
Apache License 2.0
4.57k stars 416 forks source link

Is using Schedulers.io() a mistake for initializing sqlbrite? #208

Closed schristmann closed 7 years ago

schristmann commented 7 years ago

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?

JakeWharton commented 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.

schristmann commented 7 years ago

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.

JakeWharton commented 7 years ago

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 .