Hello everyone, I have an Android method that runs in background performing some DML executions. However, if the device "Moto G" is put in sleep (I could not reproduce this error in any other device), after some minutes the Ultralite starts to thrown the following error for every single SQL execution in the opened connection:
Any ideias what is going on? I've been trying to get a solution for this, but I actually have no idea what to do next. asked 10 Nov '14, 13:49 Alex |
Finally I found the solution. To avoid the device is put in sleep we must implement an Android WakeLock:
That is enough to get rid of the I/O UltraliteJ errors. answered 11 Nov '14, 07:13 Alex 1
A WakeLock is a good approach for keeping the device awake for a short time while a critical task is happening. In general, we recommend that when your Activity is Paused or Stopped, you commit or rollback UltraLite connections and disconnect them. Then, when the Activity is Resumed, you renew the connections. This coincides with Google's recommendations on managing the Activity lifecycle (see http://developer.android.com/guide/components/activities.html#Lifecycle).
(11 Nov '14, 13:20)
Andy Quick
|
Apparently the write system call is returning an error because the device went to sleep. UltraLite is interpreting this as a file system failure and locking the database. (To recover, you must disconnect and reconnect to the database. When the database restarts, it will automatically recover to the last commit.) One solution could be to keep the device awake while the DML is running. Another could be to make your background code robust to the sleep/error by continuing from the last commit. Whether UltraLite could safely retry this call internally (i.e., a bug fix) will require some research. answered 10 Nov '14, 17:53 Tim McClements The fact the database is being locked explains why, when the device awakes, this error still happens. I'll try do make some workarounds for this scenario, but, as my application is too complex, I don't know if I'll be able to find a easy solution for it. But tks anyway by your explanation.
(11 Nov '14, 05:20)
Alex
Comment Text Removed
|