Fixed
Status Update
Comments
su...@google.com <su...@google.com> #2
hmm it should not ask for a transaction. In fact, we don't want a transaction.
Can you show us that error?
yaraki@, i think we should check if we are already in a transaction before sending vacuum and if so, print a warning and skip vacuum.
Can you show us that error?
yaraki@, i think we should check if we are already in a transaction before sending vacuum and if so, print a warning and skip vacuum.
al...@gmail.com <al...@gmail.com> #3
Hello, when I call clearAllTables Room throws an error saying that I should start a Transaction. So I did that, and now the method throws that VACUUM cannot run inside a Transaction.
al...@gmail.com <al...@gmail.com> #4
Can you share the error message saying that a Transaction is needed?
ra...@google.com <ra...@google.com> #5
I catch the exception again. As you can see below. but I have see that that error only happen when I run clearAllTables in Main Thread.
I know that we should not do that, and when I run clearAllTables in a background thread it runs without errors.
So I believe that the exception gives a wrong message.
04-02 07:04:06.133 4197-4197/br.com.mobilesales.influxlexical E/AndroidRuntime: FATAL EXCEPTION: main
Process: br.com.mobilesales.influxlexical, PID: 4197
java.lang.IllegalStateException: Cannot perform this operation because there is no current transaction.
at android.database.sqlite.SQLiteSession.throwIfNoTransaction(SQLiteSession.java:915)
at android.database.sqlite.SQLiteSession.endTransaction(SQLiteSession.java:398)
at android.database.sqlite.SQLiteDatabase.endTransaction(SQLiteDatabase.java:524)
at android.arch.persistence.db.framework.FrameworkSQLiteDatabase.endTransaction(FrameworkSQLiteDatabase.java:90)
at android.arch.persistence.room.RoomDatabase.endTransaction(RoomDatabase.java:261)
at br.com.mobilesales.influxlexical.data.source.local.AppDatabase_Impl.clearAllTables(AppDatabase_Impl.java:355)
at br.com.mobilesales.influxlexical.InfluxLexicalApplication$override.logoffUser(InfluxLexicalApplication.java:154)
at br.com.mobilesales.influxlexical.InfluxLexicalApplication$override.access$dispatch(InfluxLexicalApplication.java)
at br.com.mobilesales.influxlexical.InfluxLexicalApplication.logoffUser(InfluxLexicalApplication.java)
at br.com.mobilesales.influxlexical.MainActivity.onOptionsItemSelected(MainActivity.kt:247)
at android.app.Activity.onMenuItemSelected(Activity.java:3204)
at android.support.v4.app.FragmentActivity.onMenuItemSelected(FragmentActivity.java:380)
at android.support.v7.app.AppCompatActivity.onMenuItemSelected(AppCompatActivity.java:195)
at android.support.v7.view.WindowCallbackWrapper.onMenuItemSelected(WindowCallbackWrapper.java:108)
at android.support.v7.view.WindowCallbackWrapper.onMenuItemSelected(WindowCallbackWrapper.java:108)
at android.support.v7.app.ToolbarActionBar$2.onMenuItemClick(ToolbarActionBar.java:63)
at android.support.v7.widget.Toolbar$1.onMenuItemClick(Toolbar.java:203)
at android.support.v7.widget.ActionMenuView$MenuBuilderCallback.onMenuItemSelected(ActionMenuView.java:780)
at android.support.v7.view.menu.MenuBuilder.dispatchMenuItemSelected(MenuBuilder.java:822)
at android.support.v7.view.menu.MenuItemImpl.invoke(MenuItemImpl.java:171)
at android.support.v7.view.menu.MenuBuilder.performItemAction(MenuBuilder.java:973)
at android.support.v7.view.menu.MenuBuilder.performItemAction(MenuBuilder.java:963)
at android.support.v7.widget.ActionMenuView.invokeItem(ActionMenuView.java:624)
at android.support.v7.view.menu.ActionMenuItemView.onClick(ActionMenuItemView.java:150)
at android.view.View.performClick(View.java:5637)
at android.view.View$PerformClick.run(View.java:22429)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6119)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)
I know that we should not do that, and when I run clearAllTables in a background thread it runs without errors.
So I believe that the exception gives a wrong message.
04-02 07:04:06.133 4197-4197/br.com.mobilesales.influxlexical E/AndroidRuntime: FATAL EXCEPTION: main
Process: br.com.mobilesales.influxlexical, PID: 4197
java.lang.IllegalStateException: Cannot perform this operation because there is no current transaction.
at android.database.sqlite.SQLiteSession.throwIfNoTransaction(SQLiteSession.java:915)
at android.database.sqlite.SQLiteSession.endTransaction(SQLiteSession.java:398)
at android.database.sqlite.SQLiteDatabase.endTransaction(SQLiteDatabase.java:524)
at android.arch.persistence.db.framework.FrameworkSQLiteDatabase.endTransaction(FrameworkSQLiteDatabase.java:90)
at android.arch.persistence.room.RoomDatabase.endTransaction(RoomDatabase.java:261)
at br.com.mobilesales.influxlexical.data.source.local.AppDatabase_Impl.clearAllTables(AppDatabase_Impl.java:355)
at br.com.mobilesales.influxlexical.InfluxLexicalApplication$override.logoffUser(InfluxLexicalApplication.java:154)
at br.com.mobilesales.influxlexical.InfluxLexicalApplication$override.access$dispatch(InfluxLexicalApplication.java)
at br.com.mobilesales.influxlexical.InfluxLexicalApplication.logoffUser(InfluxLexicalApplication.java)
at br.com.mobilesales.influxlexical.MainActivity.onOptionsItemSelected(MainActivity.kt:247)
at android.app.Activity.onMenuItemSelected(Activity.java:3204)
at android.support.v4.app.FragmentActivity.onMenuItemSelected(FragmentActivity.java:380)
at android.support.v7.app.AppCompatActivity.onMenuItemSelected(AppCompatActivity.java:195)
at android.support.v7.view.WindowCallbackWrapper.onMenuItemSelected(WindowCallbackWrapper.java:108)
at android.support.v7.view.WindowCallbackWrapper.onMenuItemSelected(WindowCallbackWrapper.java:108)
at android.support.v7.app.ToolbarActionBar$2.onMenuItemClick(ToolbarActionBar.java:63)
at android.support.v7.widget.Toolbar$1.onMenuItemClick(Toolbar.java:203)
at android.support.v7.widget.ActionMenuView$MenuBuilderCallback.onMenuItemSelected(ActionMenuView.java:780)
at android.support.v7.view.menu.MenuBuilder.dispatchMenuItemSelected(MenuBuilder.java:822)
at android.support.v7.view.menu.MenuItemImpl.invoke(MenuItemImpl.java:171)
at android.support.v7.view.menu.MenuBuilder.performItemAction(MenuBuilder.java:973)
at android.support.v7.view.menu.MenuBuilder.performItemAction(MenuBuilder.java:963)
at android.support.v7.widget.ActionMenuView.invokeItem(ActionMenuView.java:624)
at android.support.v7.view.menu.ActionMenuItemView.onClick(ActionMenuItemView.java:150)
at android.view.View.performClick(View.java:5637)
at android.view.View$PerformClick.run(View.java:22429)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6119)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)
be...@gmail.com <be...@gmail.com> #6
clearAllTables is not supposed to be run in a main thread. It is annotated with @WorkerThread, and you should always run it in a background thread.
al...@gmail.com <al...@gmail.com> #7
Yeah, you have to clear app data or disable the content provider in your manifest.
be...@gmail.com <be...@gmail.com> #8
I also just filed this: https://issuetracker.google.com/79950952
Either WorkManager is too smart, or there is something wrong. I want to removeAll workers on my onCreate, and re-schedule myself everything later.
By cancelling-enqueuing I got into this snowball that ended with more than 100 jobs.
Either WorkManager is too smart, or there is something wrong. I want to removeAll workers on my onCreate, and re-schedule myself everything later.
By cancelling-enqueuing I got into this snowball that ended with more than 100 jobs.
ti...@gmail.com <ti...@gmail.com> #9
Sorry folks. This is a bug in alpha01. The fix should be a part of alpha02. Hang tight.
ra...@google.com <ra...@google.com>
al...@gmail.com <al...@gmail.com> #10
Do you know when the fix will be available?
su...@google.com <su...@google.com> #11
We're aiming for later this week.
al...@gmail.com <al...@gmail.com> #12
Awesome, I'll get to merge my branch! 😉
ya...@gmail.com <ya...@gmail.com> #13
Hi, may I know,
1) After the end of execution of OneTimeWorkRequest typed worker's doWork(), do we need to cancelAllWorkByTag explicitly to perform "clean up"?
2) After this bug fixed, is there still any hard limit, only how many active job (with different tags) we can schedule on WorkManager?
Thanks.
1) After the end of execution of OneTimeWorkRequest typed worker's doWork(), do we need to cancelAllWorkByTag explicitly to perform "clean up"?
2) After this bug fixed, is there still any hard limit, only how many active job (with different tags) we can schedule on WorkManager?
Thanks.
al...@gmail.com <al...@gmail.com> #14
No, you don't need to perform cleanup and no, there aren't any limits.
su...@google.com <su...@google.com> #15
1. You don't need to perform any cleanup. Completed OneTimeWorkRequests will not re-execute,
2. There is no limit on the number of jobs you can schedule; however, at most 100 will be sent to JobScheduler at a time. The rest will be queued up and sent when appropriate. (That being said, I would advise that you probably don't want to have hundreds of potentially active jobs at any one time.)
2. There is no limit on the number of jobs you can schedule; however, at most 100 will be sent to JobScheduler at a time. The rest will be queued up and sent when appropriate. (That being said, I would advise that you probably don't want to have hundreds of potentially active jobs at any one time.)
ni...@gmail.com <ni...@gmail.com> #16
I still have this issue with 1.0.0-alpha02, like others it seems ( https://github.com/googlecodelabs/android-workmanager/issues/16 ).
As seen on the link, every time I restart my app (using ADB Idea plugin, that kill it then start it again), the numbers of tasks scheduled in JobScheduler increments by the number of periodic tasks scheduled.
I have 4 users that went into the issue and I will use a workaround code I wrote for now.
I see it on Samsung 7.0 devices for now.
As seen on the link, every time I restart my app (using ADB Idea plugin, that kill it then start it again), the numbers of tasks scheduled in JobScheduler increments by the number of periodic tasks scheduled.
I have 4 users that went into the issue and I will use a workaround code I wrote for now.
I see it on Samsung 7.0 devices for now.
ni...@gmail.com <ni...@gmail.com> #17
Here's a sample project that reproduces the issue. I use ADB Idea Plugin with the "ADB Restart App" feature to triggers the issue.
You will see that with each restart, the jobcount from JobScheduler increases by 5, but not the one from WorkManager.
I hope someone will see this message, if I need to make another issue please tell me.
You will see that with each restart, the jobcount from JobScheduler increases by 5, but not the one from WorkManager.
I hope someone will see this message, if I need to make another issue please tell me.
al...@gmail.com <al...@gmail.com> #18
If your issue is specific to periodic work, I'd file a new issue since this one is a little different.
Description
Version used: alpha01
Devices/Android versions reproduced on: >= API 23
There are a few issues here. First of all anytime a job finishes, all jobs that aren't already running are rescheduled. Then, each job generates a new ID which creates an exponential number of jobs for the system or Play Services to manage. Instead, a job should get its ID from the unique job tag or something like that.