How can I avoid concurrency problems when using SQLite on Android?
Asked Answered
C

10

726

What would be considered the best practices when executing queries on an SQLite database within an Android app?

Is it safe to run inserts, deletes and select queries from an AsyncTask's doInBackground? Or should I use the UI Thread? I suppose that database queries can be "heavy" and should not use the UI thread as it can lock up the app - resulting in an Application Not Responding (ANR).

If I have several AsyncTasks, should they share a connection or should they open a connection each?

Are there any best practices for these scenarios?

Complaint answered 22/3, 2010 at 15:13 Comment(4)
Whatever you do, remember to sanitize your inputs if your content provider (or SQLite interface) is publicly facing!Sheepshearing
You definitely should NOT be doing db accesses from the UI thread, I can tell you that much.Tiernan
@EdwardFalk Why not? Surely there are use cases where it's valid to do this?Dissuasion
If you do any I/O, network accesses, etc. from the UI thread, the entire device freezes until the operation completes. If it completes in 1/20 second, then fine. If it takes longer, you've got a bad user experience.Tiernan
N
647

Inserts, updates, deletes and reads are generally OK from multiple threads, but Brad's answer is not correct. You have to be careful with how you create your connections and use them. There are situations where your update calls will fail, even if your database doesn't get corrupted.

The basic answer.

The SqliteOpenHelper object holds on to one database connection. It appears to offer you a read and write connection, but it really doesn't. Call the read-only, and you'll get the write database connection regardless.

So, one helper instance, one db connection. Even if you use it from multiple threads, one connection at a time. The SqliteDatabase object uses java locks to keep access serialized. So, if 100 threads have one db instance, calls to the actual on-disk database are serialized.

So, one helper, one db connection, which is serialized in java code. One thread, 1000 threads, if you use one helper instance shared between them, all of your db access code is serial. And life is good (ish).

If you try to write to the database from actual distinct connections at the same time, one will fail. It will not wait till the first is done and then write. It will simply not write your change. Worse, if you don’t call the right version of insert/update on the SQLiteDatabase, you won’t get an exception. You’ll just get a message in your LogCat, and that will be it.

So, multiple threads? Use one helper. Period. If you KNOW only one thread will be writing, you MAY be able to use multiple connections, and your reads will be faster, but buyer beware. I haven't tested that much.

Here's a blog post with far more detail and an example app.

Gray and I are actually wrapping up an ORM tool, based off of his Ormlite, that works natively with Android database implementations, and follows the safe creation/calling structure I describe in the blog post. That should be out very soon. Take a look.


In the meantime, there is a follow up blog post:

Also checkout the fork by 2point0 of the previously mentioned locking example:

Neocene answered 11/9, 2010 at 5:11 Comment(13)
As an aside, Ormlite's android support can be found at ormlite.sourceforge.net/sqlite_java_android_orm.html. There are sample projects, documentation, and jars.Bodnar
A second aside. The ormlite code has helper classes that can be used to manage dbhelper instances. You can use the ormlite stuff, but its not required. You can use the helper classes just to do connection management.Neocene
Kāgii, thank you for the detailed explanation. Could you clarify one thing -- I understand you should have ONE helper, but should you also only have one connection (i.e. one SqliteDatabase object)? In other words, how often should you call getWritableDatabase? And equally importantly when do you call close()?Valeriavalerian
I updated the code. The original was lost when I switched blog hosts, but I added some slimmed down example code that will demonstrate the issue. Also, how do you manage the single connection? I had a much more complicated solution initially, but I've since amended that. Take a look here: touchlab.co/uncategorized/single-sqlite-connectionNeocene
is there a need to dispose connection and where to do it?Hifi
I don't. The "connection" is a file handle. When the app exits it will be closed by the OS.Neocene
@KevinGalligan With only one helper, I think you still get a new SQLiteSession per thread that accesses the helper's internal database. Every time you make an sql command, the helper's database object calls getThreadSession which returns a unique session depending on your current thread from what I understand.Bevbevan
@schwiz The devil, my friend, is in the details. Notice the "lock()" business around the database calls. SQLiteOpenHelper has exactly one instance of a DB (see mDatabase: grepcode.com/file/repository.grepcode.com/java/ext/…), and the DB is paranoid about threaded access (see lock/unlock: grepcode.com/file_/repository.grepcode.com/java/ext/…). If you have proof to the contrary, please provide.Neocene
@schwiz Interesting. That will certainly need some review. If they pull that out of future versions, that would be a MAJOR issue. I would also feel somewhat responsible for a legion of apps falling apart. My original answer probably drove a lot of people to implement their db access that way. Looking at the docs, though, I think they're talking about explicit locking, not the low level stuff they put around calls. Should be monitored though. That would be huge, and bad (for me. All of our stuff assumes this works).Neocene
@KevinGalligan if you already are using a singleton it wouldn't be so bad for you. You would just have to implement the lock the exact same way they had.Bevbevan
Here is a wrapper I wrote/use which makes it slightly easier to use SQLite well in the context of android - SqlDb for AndroidMarionmarionette
Now if you call enableWriteAheadLogging() it uses multiple connections (a different one for each query) for parallel threads. The transaction wrapper functions are synchronised internally and the other threads wait instead of throwing an exception when the database is locked.Torry
Just looked at grepcode for more recent versions of this stuff, and we're probably due for an update. Not that this won't work, but there's nuance in newer versions.Neocene
S
198

Concurrent Database Access

Same article on my blog(I like formatting more)

I wrote small article which describe how to make access to your android database thread safe.


Assuming you have your own SQLiteOpenHelper.

public class DatabaseHelper extends SQLiteOpenHelper { ... }

Now you want to write data to database in separate threads.

 // Thread 1
 Context context = getApplicationContext();
 DatabaseHelper helper = new DatabaseHelper(context);
 SQLiteDatabase database = helper.getWritableDatabase();
 database.insert(…);
 database.close();

 // Thread 2
 Context context = getApplicationContext();
 DatabaseHelper helper = new DatabaseHelper(context);
 SQLiteDatabase database = helper.getWritableDatabase();
 database.insert(…);
 database.close();

You will get following message in your logcat and one of your changes will not be written.

android.database.sqlite.SQLiteDatabaseLockedException: database is locked (code 5)

This is happening because every time you create new SQLiteOpenHelper object you are actually making new database connection. If you try to write to the database from actual distinct connections at the same time, one will fail. (from answer above)

To use database with multiple threads we need to make sure we are using one database connection.

Let’s make singleton class Database Manager which will hold and return single SQLiteOpenHelper object.

public class DatabaseManager {

    private static DatabaseManager instance;
    private static SQLiteOpenHelper mDatabaseHelper;

    public static synchronized void initializeInstance(SQLiteOpenHelper helper) {
        if (instance == null) {
            instance = new DatabaseManager();
            mDatabaseHelper = helper;
        }
    }

    public static synchronized DatabaseManager getInstance() {
        if (instance == null) {
            throw new IllegalStateException(DatabaseManager.class.getSimpleName() +
                    " is not initialized, call initialize(..) method first.");
        }

        return instance;
    }

    public SQLiteDatabase getDatabase() {
        return new mDatabaseHelper.getWritableDatabase();
    }

}

Updated code which write data to database in separate threads will look like this.

 // In your application class
 DatabaseManager.initializeInstance(new MySQLiteOpenHelper());
 // Thread 1
 DatabaseManager manager = DatabaseManager.getInstance();
 SQLiteDatabase database = manager.getDatabase()
 database.insert(…);
 database.close();

 // Thread 2
 DatabaseManager manager = DatabaseManager.getInstance();
 SQLiteDatabase database = manager.getDatabase()
 database.insert(…);
 database.close();

This will bring you another crash.

java.lang.IllegalStateException: attempt to re-open an already-closed object: SQLiteDatabase

Since we are using only one database connection, method getDatabase() return same instance of SQLiteDatabase object for Thread1 and Thread2. What is happening, Thread1 may close database, while Thread2 is still using it. That’s why we have IllegalStateException crash.

We need to make sure no-one is using database and only then close it. Some folks on stackoveflow recommended to never close your SQLiteDatabase. This will result in following logcat message.

Leak found
Caused by: java.lang.IllegalStateException: SQLiteDatabase created and never closed

Working sample

public class DatabaseManager {

    private int mOpenCounter;

    private static DatabaseManager instance;
    private static SQLiteOpenHelper mDatabaseHelper;
    private SQLiteDatabase mDatabase;

    public static synchronized void initializeInstance(SQLiteOpenHelper helper) {
        if (instance == null) {
            instance = new DatabaseManager();
            mDatabaseHelper = helper;
        }
    }

    public static synchronized DatabaseManager getInstance() {
        if (instance == null) {
            throw new IllegalStateException(DatabaseManager.class.getSimpleName() +
                    " is not initialized, call initializeInstance(..) method first.");
        }

        return instance;
    }

    public synchronized SQLiteDatabase openDatabase() {
        mOpenCounter++;
        if(mOpenCounter == 1) {
            // Opening new database
            mDatabase = mDatabaseHelper.getWritableDatabase();
        }
        return mDatabase;
    }

    public synchronized void closeDatabase() {
        mOpenCounter--;
        if(mOpenCounter == 0) {
            // Closing database
            mDatabase.close();

        }
    }

}

Use it as follows.

SQLiteDatabase database = DatabaseManager.getInstance().openDatabase();
database.insert(...);
// database.close(); Don't close it directly!
DatabaseManager.getInstance().closeDatabase(); // correct way

Every time you need database you should call openDatabase() method of DatabaseManager class. Inside this method, we have a counter, which indicate how many times database is opened. If it equals to one, it means we need to create new database connection, if not, database connection is already created.

The same happens in closeDatabase() method. Every time we call this method, counter is decreased, whenever it goes to zero, we are closing database connection.


Now you should be able to use your database and be sure it's thread safe.

Security answered 15/11, 2013 at 8:50 Comment(24)
What do I do if the database is used by activites and SyncService which is running in its separate process ? <service android:name=".SyncService" android:exported="true" android:process=":sync"> If I understand correctly, the class loader for a separate process is different than for activites, so your approach won't work here ?Refinery
@Refinery DatabaseManager is thread safe singleton, so it could be used anywhere. Just don't forget to initialize it first time in your Application class - DatabaseManager.initializeInstance(getApplicationContext());Security
I'm one of those people who suggest you never close the db. You only get a "Leak found" error if you open the db, don't close it, then try to open again. If you only use a single open helper, and never close the db, you don't get that error. If you find otherwise, please let me know (with code). I had a longer post about it somewhere, but can't find it. Question answered by commonsware here, who kind of outguns us both in the SO points department: #7212441Neocene
More thoughts. #1, I'd create the helper inside your manager. Asking for problems to have it outside. New dev might call the helper directly for some crazy reason. Also, if you're going to require an init method, throw an exception if instance already exists. Multi-db apps will obviously fail as is. #2, why the mDatabase field? Its available from helper. #3, as your first step towards "never close", what happens to your db when your app crashes and isn't "closed"? Hint, nothing. Its fine, because SQLite is super stable. That was step 1 in figuring out why you don't need to close it.Neocene
Any reason why you use a public initialize method to call prior to getting the instance? Why not have a private constructor that's called if(instance==null)? You leave no choice but to call initialize every time; how else would you know if it has been initialized or not in other applications etc?Hoopen
@DmytroDanylyk can you give an example how can i use my own methods like getAllEntries() using your manager architecture?Statutable
initializeInstance() has a parameter of type SQLiteOpenHelper, but in your comment you mentioned to use DatabaseManager.initializeInstance(getApplicationContext());. What is going on? How can this possibly work?Fumigator
@Fumigator as I already told, first you need to init your singleton DatabaseManager.initializeInstance(getApplicationContext()); then you can use it as in example above.Security
In your code, the only way to init the singleton is to call initializeInstance(SQLiteOpenHelper helper). How can i pass a Context object where a SQLiteOpenHelper object is required?Fumigator
@Fumigator I fixed the code, because it was changing I missed correct method name. Thanks for discovering issue!Security
I am not sure why you have gone for such a lengthy solution. I implemented a simple singleton pattern without ever closing the helper object. I never got the IllegalStateException and it works just fine till now. https://mcmap.net/q/64491/-how-to-make-sqlite-connections-more-efficientFumigator
@DmytroDanylyk "DatabaseManager is thread safe singleton, so it could be used anywhere" that's not true in response to virsir 's question. Object's are not shared cross processes. Your DatabaseManager will have no state in a different process like in a sync adapter (android:process=":sync")Raila
@Raila that's true.Security
@DmytroDanylyk thanks for that post, I'm going to implement this as currently I simply do not close database connections. One little thing I noticed - if an int (mOpenCounter) is going to be accessed by multiple threads, it's probably better to use AtomicInteger instead - that's why this class exists.Intellect
I need to call my methods in the helper, could be the correct way returning the helper instance from initializeInstance() and then using that in code?Anthiathia
Will it throw a 'attempting to open an already closed database object' while, all my I have successfully closed the database and then one of my calls openDatabase() again? I guess it is doing in my case.Gingerich
@DmytroDanylyk: If i use db.beginTransaction() then I still face the locked exception issue. If i do not use it then the problem is solved. I do want to use database transactions as they are faster for huge inserts of data. Can you suggest on this ? Thanks!Clemmie
Excelent Idea!!! thank you so much!. I used this approach with a inner SQLiteOpenHelper. No problem at all. Tested running over 100 async tasks at the same time performing selects/inserts on the same db, and also making linear operations!!!!Masurium
@DmytroDanylyk But this again return same DB object to multiple thread, isn't be same issue again where Sqlite do not allow simultaneous WRITE operation. Correct me if I'm wrong.Platitudinous
@Platitudinous if you use same database connection (as in example above) your are fine.Security
How can I modify to return Readable or Writable SQLiteDatabase object based on the request, rather return Writable SQLiteDatabase object all the time?Exploiter
@IlanthirayanParamanathan just declare two SQLiteDatabase variables or make two DatabaseManager, WriteDatabaseManager and Read DatabaseManager.Security
@DmytroDanylyk, I have tried, having two variables, one for reading and another one for writing, but it is crashing the app. I am just wondering, with two DatabaseManagers pointing to the same database, will trying to write something into the database with one manager while another is reading it cause a problem?Exploiter
@DmytroDanylyk but why do you try to close database from each thread? Isn't this should be done only from one method, like onDestroy?Nath
S
18
  • Use a Thread or AsyncTask for long-running operations (50ms+). Test your app to see where that is. Most operations (probably) don't require a thread, because most operations (probably) only involve a few rows. Use a thread for bulk operations.
  • Share one SQLiteDatabase instance for each DB on disk between threads and implement a counting system to keep track of open connections.

Are there any best practices for these scenarios?

Share a static field between all your classes. I used to keep a singleton around for that and other things that need to be shared. A counting scheme (generally using AtomicInteger) also should be used to make sure you never close the database early or leave it open.

My solution:

The old version I wrote is available at https://github.com/Taeluf/dev/tree/main/archived/databasemanager and is not maintained. If you want to understand my solution, look at the code and read my notes. My notes are usually pretty helpful.

  1. copy/paste the code into a new file named DatabaseManager. (or download it from github)
  2. extend DatabaseManager and implement onCreate and onUpgrade like you normally would. You can create multiple subclasses of the one DatabaseManager class in order to have different databases on disk.
  3. Instantiate your subclass and call getDb() to use the SQLiteDatabase class.
  4. Call close() for each subclass you instantiated

The code to copy/paste:

import android.content.Context;
import android.database.sqlite.SQLiteDatabase;

import java.util.concurrent.ConcurrentHashMap;

/** Extend this class and use it as an SQLiteOpenHelper class
 *
 * DO NOT distribute, sell, or present this code as your own. 
 * for any distributing/selling, or whatever, see the info at the link below
 *
 * Distribution, attribution, legal stuff,
 * See https://github.com/JakarCo/databasemanager
 * 
 * If you ever need help with this code, contact me at [email protected] (or [email protected] )
 * 
 * Do not sell this. but use it as much as you want. There are no implied or express warranties with this code. 
 *
 * This is a simple database manager class which makes threading/synchronization super easy.
 *
 * Extend this class and use it like an SQLiteOpenHelper, but use it as follows:
 *  Instantiate this class once in each thread that uses the database. 
 *  Make sure to call {@link #close()} on every opened instance of this class
 *  If it is closed, then call {@link #open()} before using again.
 * 
 * Call {@link #getDb()} to get an instance of the underlying SQLiteDatabse class (which is synchronized)
 *
 * I also implement this system (well, it's very similar) in my <a href="http://androidslitelibrary.com">Android SQLite Libray</a> at http://androidslitelibrary.com
 * 
 *
 */
abstract public class DatabaseManager {
    
    /**See SQLiteOpenHelper documentation
    */
    abstract public void onCreate(SQLiteDatabase db);
    /**See SQLiteOpenHelper documentation
     */
    abstract public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion);
    /**Optional.
     * *
     */
    public void onOpen(SQLiteDatabase db){}
    /**Optional.
     * 
     */
    public void onDowngrade(SQLiteDatabase db, int oldVersion, int newVersion) {}
    /**Optional
     * 
     */
    public void onConfigure(SQLiteDatabase db){}



    /** The SQLiteOpenHelper class is not actually used by your application.
     *
     */
    static private class DBSQLiteOpenHelper extends SQLiteOpenHelper {

        DatabaseManager databaseManager;
        private AtomicInteger counter = new AtomicInteger(0);

        public DBSQLiteOpenHelper(Context context, String name, int version, DatabaseManager databaseManager) {
            super(context, name, null, version);
            this.databaseManager = databaseManager;
        }

        public void addConnection(){
            counter.incrementAndGet();
        }
        public void removeConnection(){
            counter.decrementAndGet();
        }
        public int getCounter() {
            return counter.get();
        }
        @Override
        public void onCreate(SQLiteDatabase db) {
            databaseManager.onCreate(db);
        }

        @Override
        public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
            databaseManager.onUpgrade(db, oldVersion, newVersion);
        }

        @Override
        public void onOpen(SQLiteDatabase db) {
            databaseManager.onOpen(db);
        }

        @Override
        public void onDowngrade(SQLiteDatabase db, int oldVersion, int newVersion) {
            databaseManager.onDowngrade(db, oldVersion, newVersion);
        }

        @Override
        public void onConfigure(SQLiteDatabase db) {
            databaseManager.onConfigure(db);
        }
    }

    private static final ConcurrentHashMap<String,DBSQLiteOpenHelper> dbMap = new ConcurrentHashMap<String, DBSQLiteOpenHelper>();

    private static final Object lockObject = new Object();


    private DBSQLiteOpenHelper sqLiteOpenHelper;
    private SQLiteDatabase db;
    private Context context;

    /** Instantiate a new DB Helper. 
     * <br> SQLiteOpenHelpers are statically cached so they (and their internally cached SQLiteDatabases) will be reused for concurrency
     *
     * @param context Any {@link android.content.Context} belonging to your package.
     * @param name The database name. This may be anything you like. Adding a file extension is not required and any file extension you would like to use is fine.
     * @param version the database version.
     */
    public DatabaseManager(Context context, String name, int version) {
        String dbPath = context.getApplicationContext().getDatabasePath(name).getAbsolutePath();
        synchronized (lockObject) {
            sqLiteOpenHelper = dbMap.get(dbPath);
            if (sqLiteOpenHelper==null) {
                sqLiteOpenHelper = new DBSQLiteOpenHelper(context, name, version, this);
                dbMap.put(dbPath,sqLiteOpenHelper);
            }
            //SQLiteOpenHelper class caches the SQLiteDatabase, so this will be the same SQLiteDatabase object every time
            db = sqLiteOpenHelper.getWritableDatabase();
        }
        this.context = context.getApplicationContext();
    }
    /**Get the writable SQLiteDatabase
     */
    public SQLiteDatabase getDb(){
        return db;
    }

    /** Check if the underlying SQLiteDatabase is open
     *
     * @return whether the DB is open or not
     */
    public boolean isOpen(){
        return (db!=null&&db.isOpen());
    }


    /** Lowers the DB counter by 1 for any {@link DatabaseManager}s referencing the same DB on disk
     *  <br />If the new counter is 0, then the database will be closed.
     *  <br /><br />This needs to be called before application exit.
     * <br />If the counter is 0, then the underlying SQLiteDatabase is <b>null</b> until another DatabaseManager is instantiated or you call {@link #open()}
     *
     * @return true if the underlying {@link android.database.sqlite.SQLiteDatabase} is closed (counter is 0), and false otherwise (counter > 0)
     */
    public boolean close(){
        sqLiteOpenHelper.removeConnection();
        if (sqLiteOpenHelper.getCounter()==0){
            synchronized (lockObject){
                if (db.inTransaction())db.endTransaction();
                if (db.isOpen())db.close();
                db = null;
            }
            return true;
        }
        return false;
    }
    /** Increments the internal db counter by one and opens the db if needed
    *
    */
    public void open(){
        sqLiteOpenHelper.addConnection();
        if (db==null||!db.isOpen()){
                synchronized (lockObject){
                    db = sqLiteOpenHelper.getWritableDatabase();
                }
        } 
    }
}
Sneak answered 29/10, 2014 at 23:14 Comment(6)
What happens when you call "close" and then try to re-use the class? will it crash? or will it automatically re-initialize itself to be able to use the DB again?Winebaum
@androiddeveloper, If you call close, you have to call open again before using the same instance of the class OR you can create a new instance. Since in the close code, I set db=null, you wouldn't be able to use the return value from getDb (since it would be null), so you'd get a NullPointerException if you did something like myInstance.close(); myInstance.getDb().query(...);Sneak
Why not combine getDb() and open() into a single method?Idiocy
@Burdu, A mix of providing extra control over the database counter and bad design. It's definitely not the best way to do it, though. I'll update it in a few days.Sneak
@Burdu, I just updated it. You can get the new code from here. I haven't tested it, so please let me know if I should commit the changes.Sneak
When would you remove the sqLiteOpenHelper instance from the dbMap?Middleoftheroader
L
14

The Database is very flexible with multi-threading. My apps hit their DBs from many different threads simultaneously and it does just fine. In some cases I have multiple processes hitting the DB simultaneously and that works fine too.

Your async tasks - use the same connection when you can, but if you have to, its OK to access the DB from different tasks.

Leatherneck answered 22/3, 2010 at 16:14 Comment(6)
Also, do you have readers and writers in different connections or should they share a single connection? Thanks.Bodnar
@Bodnar - correct, I should have mentioned that explicitly. As far as connections, I would use the same connection as much as possible, but since the locking is handled at the filesystem level, you can open it multiple times in the code, but I would use a single connection as much as possible. The Android sqlite DB is very flexible and forgiving.Leatherneck
@Gray, just wanted to post an updated information for people who may be using this method. Documentation says: This method now does nothing. Do not use.Thimbleful
I've found this method to fail horribly, we are switching to ContentProvider to access from multiple applications. We will have to do some concurrency on our methods but that should fix any issues with processes all accessing the data at the same time.Shalon
I know this is old, but it's incorrect. It might work out okay to access DB from different SQLiteDatabase objects on different AsyncTasks/Threads, but it will sometimes lead to errors which is why SQLiteDatabase (line 1297) uses LocksSneak
Well what happens when you call .sqLiteHelper.close (e.g. in onDestroy) while some other thread does db.update or db.insert and etc? Or you never call .sqLiteHelper.close?Nath
G
9

after struggling with this for a couple of hours, I've found that you can only use one db helper object per db execution. For example,

for(int x = 0; x < someMaxValue; x++)
{
    db = new DBAdapter(this);
    try
    {

        db.addRow
        (
                NamesStringArray[i].toString(), 
                StartTimeStringArray[i].toString(),
                EndTimeStringArray[i].toString()
        );

    }
    catch (Exception e)
    {
        Log.e("Add Error", e.toString());
        e.printStackTrace();
    }
    db.close();
}

as apposed to:

db = new DBAdapter(this);
for(int x = 0; x < someMaxValue; x++)
{

    try
    {
        // ask the database manager to add a row given the two strings
        db.addRow
        (
                NamesStringArray[i].toString(), 
                StartTimeStringArray[i].toString(),
                EndTimeStringArray[i].toString()
        );

    }
    catch (Exception e)
    {
        Log.e("Add Error", e.toString());
        e.printStackTrace();
    }

}
db.close();

creating a new DBAdapter each time the loop iterates was the only way I could get my strings into a database through my helper class.

Gorlicki answered 29/6, 2011 at 7:22 Comment(0)
T
8

Dmytro's answer works fine for my case. I think it's better to declare the function as synchronized. at least for my case, it would invoke null pointer exception otherwise, e.g. getWritableDatabase not yet returned in one thread and openDatabse called in another thread meantime.

public synchronized SQLiteDatabase openDatabase() {
    if(mOpenCounter.incrementAndGet() == 1) {
        // Opening new database
        mDatabase = mDatabaseHelper.getWritableDatabase();
    }
    return mDatabase;
}
Teter answered 7/1, 2014 at 9:1 Comment(1)
mDatabaseHelper.getWritableDatabase(); This won't create new database objectJalopy
B
6

You can try to apply new architecture approach anounced at Google I/O 2017.

It also includes new ORM library called Room

It contains three main components: @Entity, @Dao and @Database

User.java

@Entity
public class User {
  @PrimaryKey
  private int uid;

  @ColumnInfo(name = "first_name")
  private String firstName;

  @ColumnInfo(name = "last_name")
  private String lastName;

  // Getters and setters are ignored for brevity,
  // but they're required for Room to work.
}

UserDao.java

@Dao
public interface UserDao {
  @Query("SELECT * FROM user")
  List<User> getAll();

  @Query("SELECT * FROM user WHERE uid IN (:userIds)")
  List<User> loadAllByIds(int[] userIds);

  @Query("SELECT * FROM user WHERE first_name LIKE :first AND "
       + "last_name LIKE :last LIMIT 1")
  User findByName(String first, String last);

  @Insert
  void insertAll(User... users);

  @Delete
  void delete(User user);
}

AppDatabase.java

@Database(entities = {User.class}, version = 1)
public abstract class AppDatabase extends RoomDatabase {
  public abstract UserDao userDao();
}
Bandog answered 23/5, 2017 at 19:17 Comment(1)
I don't suggest Room to a Database with multiple N-to-N relationships, because it doesn't handle this approach well and you have to write a lot of code to find a workaround for these relationships.Stalnaker
C
5

My understanding of SQLiteDatabase APIs is that in case you have a multi threaded application, you cannot afford to have more than a 1 SQLiteDatabase object pointing to a single database.

The object definitely can be created but the inserts/updates fail if different threads/processes (too) start using different SQLiteDatabase objects (like how we use in JDBC Connection).

The only solution here is to stick with 1 SQLiteDatabase objects and whenever a startTransaction() is used in more than 1 thread, Android manages the locking across different threads and allows only 1 thread at a time to have exclusive update access.

Also you can do "Reads" from the database and use the same SQLiteDatabase object in a different thread (while another thread writes) and there would never be database corruption i.e "read thread" wouldn't read the data from the database till the "write thread" commits the data although both use the same SQLiteDatabase object.

This is different from how connection object is in JDBC where if you pass around (use the same) the connection object between read and write threads then we would likely be printing uncommitted data too.

In my enterprise application, I try to use conditional checks so that the UI Thread never have to wait, while the BG thread holds the SQLiteDatabase object (exclusively). I try to predict UI Actions and defer BG thread from running for 'x' seconds. Also one can maintain PriorityQueue to manage handing out SQLiteDatabase Connection objects so that the UI Thread gets it first.

Counterfeit answered 3/2, 2011 at 9:35 Comment(3)
And what do you put into that PriorityQueue - listeners (that want to get database object) or SQL queries?Thimbleful
I haven't use the priority queue approach, but essentially the "caller" threads.Counterfeit
@Swaroop: PCMIIW,"read thread" wouldn't read the data from the database till the "write thread" commits the data although both use the same SQLiteDatabase object. This is not true always, if you start "read thread" just after "write thread" you might not get the newly updated data(inserted or updated in write thread). Read thread might read the data prior to start of write thread. This happens because write operation initially enable Reserved lock instead of exclusive lock.Addend
L
3

Having had some issues, I think I have understood why I have been going wrong.

I had written a database wrapper class which included a close() which called the helper close as a mirror of open() which called getWriteableDatabase and then have migrated to a ContentProvider. The model for ContentProvider does not use SQLiteDatabase.close() which I think is a big clue as the code does use getWriteableDatabase In some instances I was still doing direct access (screen validation queries in the main so I migrated to a getWriteableDatabase/rawQuery model.

I use a singleton and there is the slightly ominous comment in the close documentation

Close any open database object

(my bolding).

So I have had intermittent crashes where I use background threads to access the database and they run at the same time as foreground.

So I think close() forces the database to close regardless of any other threads holding references - so close() itself is not simply undoing the matching getWriteableDatabase but force closing any open requests. Most of the time this is not a problem as the code is single threading, but in multi-threaded cases there is always the chance of opening and closing out of sync.

Having read comments elsewhere that explains that the SqLiteDatabaseHelper code instance counts, then the only time you want a close is where you want the situation where you want to do a backup copy, and you want to force all connections to be closed and force SqLite to write away any cached stuff that might be loitering about - in other words stop all application database activity, close just in case the Helper has lost track, do any file level activity (backup/restore) then start all over again.

Although it sounds like a good idea to try and close in a controlled fashion, the reality is that Android reserves the right to trash your VM so any closing is reducing the risk of cached updates not being written, but it cannot be guaranteed if the device is stressed, and if you have correctly freed your cursors and references to databases (which should not be static members) then the helper will have closed the database anyway.

So my take is that the approach is:

Use getWriteableDatabase to open from a singleton wrapper. (I used a derived application class to provide the application context from a static to resolve the need for a context).

Never directly call close.

Never store the resultant database in any object that does not have an obvious scope and rely on reference counting to trigger an implicit close().

If doing file level handling, bring all database activity to a halt and then call close just in case there is a runaway thread on the assumption that you write proper transactions so the runaway thread will fail and the closed database will at least have proper transactions rather than potentially a file level copy of a partial transaction.

Liaoning answered 3/3, 2017 at 21:47 Comment(0)
D
0

I know that the response is late, but the best way to execute sqlite queries in android is through a custom content provider. In that way the UI is decoupled with the database class(the class that extends the SQLiteOpenHelper class). Also the queries are executed in a background thread(Cursor Loader).

Dragline answered 24/11, 2017 at 6:13 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.