Data stay in .db-wal or .db-shm file when conection of SQLite 3 was not closed

Question

I am using SQLite3 in my Android App for data storing from Bluetooth LE. There are two occurrences when the SQLite is used:

• First when I check after scanning that the Bluetooth LE Device had been already connected before. There is no problem I open connection, read or save data, and close connection. Then in Device Explorer, I see only one file with .db extension where data is properly stored. I can read this file for example with some viewer: sqliteonline.com
• Second I open the connection in service which is running on the background. The app can be logging and store data from BLE although the App or the Activity is not visible (I need this feature). But when the system kills the service or I kill the app from the launcher the connection is not closed and there stay next two files (.db-wal and .db-shm) where the last saved data are probably stored. I can see last stored data in .db file and the other files are not possible to open and read for me. The app can read the last stored data (so also from .db-wal and .db-shm files).

My ask is: Is this the correct solution? Is it possible to let the connection open? I won't delete the last stored data by some system cleaner for example. Also, I want to see all of my data during app development. I call closing connection in onDestroy method in service but I read that it is not recommended for release.

@Override
public void onDestroy() {
    if(writableTestbedDb != null){
       writableTestbedDb.close();
    }
    if(testbedDbHelper != null) {
        testbedDbHelper.close();
    }
    Log.w(TAG, "SERVICE DESTROYED");
    this.stopSelf();
    super.onDestroy();
}

I using a singleton design pattern for database connection.

public static TestbedDbHelper getInstance(Context context) {

    if (mInstance == null) {
        mInstance = new TestbedDbHelper(context.getApplicationContext());
    }
    mInstance.setWriteAheadLoggingEnabled(false);
    return mInstance;
}

Answer 1

This happens because you use write-ahead logging. I see that you have the code to disable it, but somehow you still use it. Nevertheless, these files (wal & shm) are OK generally and there is nothing wrong with them. But if you want to make sure that you have only one file (.db), you can execute somewhere in your code:

pragma wal_checkpoint

to ensure everything is cleared. You can do it, for example, right after you open your db instance. This will save all the data that remained unsaved from the previous time - to the main file.