@Insert(onConflict = OnConflictStrategy.ROLLBACK) causes SQLiteException: cannot rollback - no transaction is active [117266738]

Fixed

Bug

Status Update

No update yet.

Description

gm...@gmail.com

created issue #1

Oct 4, 2018 10:23PM

Component used: Room
Version used: 2.0.0
Devices/Android versions reproduced on: Wileyfox Swift (API 25)
Not reproduced on Android Emulator API 15 (probably due to different SQLite version).

SQLite constraint violation on method annotated with @Insert(onConflict = OnConflictStrategy.ROLLBACK) causes SQLiteException instead of SQLiteConstraintException.

Stack trace example:
E/AndroidRuntime: FATAL EXCEPTION: Thread-8
Process: gmk57.roomtest, PID: 2152
android.database.sqlite.SQLiteException: cannot rollback - no transaction is active (code 1)
at android.database.sqlite.SQLiteConnection.nativeExecute(Native Method)
at android.database.sqlite.SQLiteConnection.execute(SQLiteConnection.java:555)
at android.database.sqlite.SQLiteSession.endTransactionUnchecked(SQLiteSession.java:439)
at android.database.sqlite.SQLiteSession.endTransaction(SQLiteSession.java:401)
at android.database.sqlite.SQLiteDatabase.endTransaction(SQLiteDatabase.java:524)
at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.endTransaction(FrameworkSQLiteDatabase.java:90)
at androidx.room.RoomDatabase.endTransaction(RoomDatabase.java:266)
at gmk57.roomtest.DataDao_Impl.insertRollback(DataDao_Impl.java:99)
at gmk57.roomtest.MainActivity.violateRollback(MainActivity.java:67)

Taking into account that
1) Room wraps methods annotated with @Insert, @Update and @Transaction in explicit transaction, and
2) ABORT, FAIL and ROLLBACK all throw SQLiteConstraintException, effectively rolling back this transaction
- the broader question is: is there any reason to provide FAIL and ROLLBACK options at all?

I also think the documentation should clearly describe the behavior of each strategy in specific case of Android + Room (e.g. which strategies throw an exception and which do not), instead of just linking to partly irrelevant SQLite documentation.

Sample project attached.

RoomTest.zip

135 KB

Download

Comments

yb...@google.com <yb...@google.com> Oct 4, 2018 10:30PM

Reassigned to da...@google.com.

ya...@google.com <ya...@google.com> Nov 29, 2018 06:46AM

Accepted by ya...@google.com.

ya...@google.com <ya...@google.com> #2Nov 29, 2018 08:13AM

Bringing setMaxSchedulerLimit to say 49 doesn't help. Same error.

gm...@gmail.com <gm...@gmail.com> #3Nov 29, 2018 08:37AM

If you are using work-firebase then you should not be using JobScheduler directly. Can you please send us the full bug report so we can investigate ?

ya...@google.com <ya...@google.com> #4Jan 7, 2019 06:51AM

java.lang.IllegalStateException: Apps may not schedule more than 100 distinct jobs
at android.os.Parcel.readException(Parcel.java:1692)
at android.os.Parcel.readException(Parcel.java:1637)
at android.app.job.IJobScheduler$Stub$Proxy.schedule(IJobScheduler.java:158)
at android.app.JobSchedulerImpl.schedule(JobSchedulerImpl.java:42)
at androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal(SystemJobScheduler.java:126)
at androidx.work.impl.background.systemjob.SystemJobScheduler.schedule(SystemJobScheduler.java:95)
at androidx.work.impl.Schedulers.scheduleInternal(Schedulers.java:104)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:73)
at androidx.work.impl.WorkerWrapper.setSucceededAndNotify(WorkerWrapper.java:393)
at androidx.work.impl.WorkerWrapper.handleResult(WorkerWrapper.java:255)
at androidx.work.impl.WorkerWrapper.run(WorkerWrapper.java:181)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)

gm...@gmail.com <gm...@gmail.com> #5Jan 7, 2019 06:07PM

What do you mean I shouldn't use JobScheduler directly? Isn't work-firebase is just for <21 devices, otherwise JobScheduler always used?

ya...@google.com <ya...@google.com> #6Jan 21, 2019 07:25AM

I think i was confused by your previous comment. You are right, we only use work-firebase for API < 23.
JobScheduler is used for API >= 23.

This issue should have been resolved in `alpha03` and `alpha04` (we addressed different parts of the problem). If you can reproduce this on a device, then can you do:

1. adb shell dumpsys jobscheduler for your app.
2. Reboot your device.
3. After the reboot, can you re-run adb shell dumpsys jobscheduler ?

I want to check if you see any differences in the jobs created before and after the reboot.

Thanks for your patience.

ap...@google.com <ap...@google.com> #7Jan 25, 2019 06:58PM

Actually for step 2, the easier thing to do is to force stop your app. You don't need to fo a full reboot.

ya...@google.com <ya...@google.com> Jan 28, 2019 02:35AM

Marked as fixed.