# Single SQLite connection - Kevin Galligan

DevFeed: [Single SQLite connection - Kevin Galligan](<https://devfeed.tech/articles/single-sqlite-connection-kevin-galligan-38049.md>)

Original publisher: [Read original article](<https://touchlab.co/2011-10-single-sqlite-connection>)

Published: 2011-10-15T04:00:00Z

Content type: tutorial

Language: en

Sources: [Touchlab | Enterprise Mobile Innovation & Development](<https://devfeed.tech/sources/touchlab-enterprise-mobile-innovation-development.md>)

Topics: [SQLite](<https://devfeed.tech/topics/sqlite.md>), [Android](<https://devfeed.tech/topics/android.md>), [locking](<https://devfeed.tech/topics/locking.md>), [Databases](<https://devfeed.tech/topics/databases.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [databases](<https://devfeed.tech/tags/databases.md>), [locking](<https://devfeed.tech/tags/locking.md>), [sqlite](<https://devfeed.tech/tags/sqlite.md>), [thoughts](<https://devfeed.tech/tags/thoughts.md>)

## AI overview

The article recommends using one statically held SQLiteOpenHelper instance in an Android app, initialized lazily with synchronization, instead of opening multiple SQLite connections. It argues that the connection can remain open for the app's lifetime and that the reported close exception occurs when another connection is opened while one already holds a file lock.

## Source excerpt

If you look back at my earlier post, android sqlite locking, I demonstrated that more than one sqlite connection was really bad. Bad-bad. OK, so now what? How do you keep one connection and manage it? Back when I worked on some earlier versions of ORMLite, I coded this big, complex framework that would do reference counting, and close the connection when nobody had a reference to it, and that worked pretty good. The downside?