Please, give me some examples of the kinds of things you are doing which could benefit from improved concurrency.
* What SQL are you running that takes more than a fraction of a second to complete?
* Are you holding transactions open for an extended period of time? Why?
My embedded application has a severe limitation: writing to flash memory, used as permanent storage, is very slow.
A backend process collects data which takes 2 to 10 min, speed is limited by IO bandwidth.
Commit'ing each change to flash would slow down the whole process around factor 5. RAM is scarce and in-memory DBs therefore not an option.
For user feedback, a second process tries every 15 s to read the number of data sets processed so far.
I do not see which kind of sqlite changes could help here. So I will just have to handle it in a layer above or besides the DB. (or commit every x seconds and live with some slow-down)
* How many processes do you have trying to access the database
at once?
just those two
* How do you currently handle SQLITE_BUSY replies? Do you use
the sqlite_busy_handler() or sqlite_busy_timeout() APIs?
timeout
* How large are your databases?
2 to 30 MB (on a 64 MB flash)
* Do you ever put database files on a shared filesystem?
no
Overall, I prefer sqlite's ease of use and (large) SQL conformity over any kind of proprietary extension or increased complexity.
Frank
P.S.: thanks for a great database!
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
