UltraliteJ I/O error if device sleeps

[Former Member]

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:

Error[-305]: I/O error 200020 [Interrupted system call,0,312]


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.

[Former Member · Accepted solution]

Finally I found the solution. To avoid the device is put in sleep we must implement an Android WakeLock:

PowerManager powerManager = (PowerManager) context.getSystemService(Context.POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(
PowerManager.PARTIAL_WAKE_LOCK, "MyWakelockTag");

wakeLock.acquire();
// Do some heavy DML executions in background
wakeLock.release();


That is enough to get rid of the I/O UltraliteJ errors.

[Vlad · Accepted solution]

Thank you for posting the solution, Alex!

[Former Member · Accepted solution]

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).

[former_SQLA_member1694876]

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.

[Former Member]

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.