[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sqlite-users
Subject:    Re: [sqlite] Concurrency in SQLite
From:       Frank Baumgart <godot () uni-paderborn ! de>
Date:       2003-11-23 22:26:46
[Download RAW message or body]

> 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: sqlite-users-unsubscribe@sqlite.org
For additional commands, e-mail: sqlite-users-help@sqlite.org

[prev in list] [next in list] [prev in thread] [next in thread]