On 02/07/14 12:20, Simon Slavin wrote:
On 2 Jul 2014, at 12:02pm, Grzegorz Sikorski <g.sikor...@kelvatek.com> wrote:
My code works fine up to about 1020 connections to the database. After around this
number, I get an error "unable to open database file". [snip]
This should not happen. But I don't know why it would happen. I have seen
individual apps make more than 5000 connections to SQLite databases (not
concurrently, but closing one before opening another) without problems. Mind
you, that was on a desktop computer, not under iOS.
My application has to deal with concurrent connections to different
database files and sometimes do ATTACH/DETACH to another file (due to
sharding).
Please make sure you are checking the results returned by /all/ sqlite3_ calls,
including _close(), and reporting all errors. Don't check just the results
returned by operations which make changes to the database. But if everything
returns SQLITE_OK then you shouldn't be having those problems. Please post
more info, perhaps with the extended error code.
I double checked, I always have SQLITE_OK from all calls up to one which
gives me this error (note it is not always sqlite_open_v2, sometimes it
can happen on step or close calls). Is there any simple way to get
extended error codes you mentioned form C/C++ level? I haven't seen any
API (I use sqlite3_errmsg, sqlite3_errstr and sqlite3_errcode).
I am not sure if there is any reason why keeping opened connection in whole
application lifetime is really something I should do? I would prefer to open
database only when it is needed, to avoid risk of file corruption on power loss.
If your app uses one database during one 'run', and need frequent access to it,
there is no need to keep closing and reopening your database. As long as you
use transactions properly and do not disable proper journal handing, you will
find that SQLite is rock solid and you do not need to keep closing a database
to make sure it is updated.
This is probably true for SQLite3, however there is not many file
systems which guarantee the same level of confidence on power loss. We
especially observe frequent corruptions on most file systems (VFAT,
EXT3, EXT4, UBIFS) on FLASH type devices like microSD and raw NAND FLASH
(even up to 30% cases). EXT4 on microSD with the safest mounting options
gives us best results (corruption chance less that 10%, depending on SD
card type). On HDD over SATA however, chances are extremely low (less
than 3% of cases). We performed tests on several kernel versions with
different drivers and have confirmation from EXT4 team that this is
something they are aware, because they could not deal with all of
devices and optimized the file system for most common HDDs.
Under iOS you should, of course, close the database when your app quits. And
you may also want to close it for the following notifications:
applicationWillResignActive:
applicationDidEnterBackground:
and reopen it for
applicationDidBecomeActive:
applicationWillEnterForeground:
It's possible that your app might want to do processing while in the background
so you might not want to close in response to 'applicationDidEnterBackground:'.
I am using PC with Ubuntu 14.04.
Alternatively instead of opening the database on 'start' and 'wake' you can
keep track of its 'open' status in a boolean variable and check it before each
database operation. This would allow an application to open a database
connection only when needed, then keep it open until the next suspend,
background, or quit.
I modified my code just to "fake" close for higher level layer and keep
the connection open if there is no need for closing. With this small
modification, the same application is able to perform more than 20000
operations with no errors.
Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
--
ExchangeDefender Message Security: Click below to verify authenticity
https://admin.exchangedefender.com/verify.php?id=s62C0tBj025421&from=g.sikor...@camlintechnologies.com
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
