As with lots of things in computer programming, there is no single "correct proceed" for the timing of closing a SQLite database (via close()
on SQLiteOpenHelper
if you are using that, or close()
on SQLiteDatabase
otherwise).app
The one fairly hard-and-fast rule is to not use multiple SQLiteDatabase
objects for the same database across multiple threads at the same time. That can get you in trouble, unless you are doing your own thread synchronization. If you stick to one SQLiteDatabase
object per database, thread synchronization is handled inside the SQLiteDatabase
.less
Because of the one-database-for-all-threads rule, and because in many cases tracking when threads may or may not want the database can be tricky when you have many different components, some developers take the approach of having a singleton database manager, which lazy-opens the database... and never closes it. For example, a database-backed ContentProvider
uses this pattern, as a ContentProvider
is never destroyed, so there is no clear time when to close the database.ide
Personally, I would go that route over the open-use-close approach, particularly if you are using SQLCipher for Android (an encrypted SQLite replacement). However, there is nothing especially wrong with the open-use-close approach if you are sure that only one thread at a time will be working with the database.this
If only a single component uses the database, there is nothing wrong with triggering opening the database in onCreate()
and closing it in onDestroy()
. After all, if that is the only component that needs the database, you do not need the database when the component itself goes away.code
Close your db in onDestroy() Comments: "OnDestroy() does not get called always! Use onStop()!" --> So onStart() has to open it.component
If onDestroy()
does not get called on a component, either you crashed with an unhandled exception in that component, or your process was terminated. The latter scenario is not a problem (again, this is how a ContentProvider
works, since a provider is never destroyed). The former scenario should not be a problem, so long as you do not accidentally use that older SQLiteDatabase
and some newer SQLiteDatabase
at the same time across multiple threads.orm
The db works efficiently. No need to close it.ip
It is not a matter of efficiency. SQLite is transactional. Failing to close a database is not a problem, as there are no unflushed buffers or something that you have to worry about.ci
Open your db once and create a field and an accessor.get
That has nothing directly to do with when you close a database.
Close after use.
That is a pattern, and done properly it can work.r