> It looks to me that several users are (a) in a uniprocess environment,
> and (b) inventing their own SQLite db access synchronization code. An
> SQLite fine grained lock manager for threads in a single process would
> address these same issues, with better concurrency as well.
>
I'm all for fine
At 16:21 24/11/2003, Doug Currie wrote:
It looks to me that several users are (a) in a uniprocess environment,
and (b) inventing their own SQLite db access synchronization code. An
SQLite fine grained lock manager for threads in a single process would
address these same issues, with better concurre
Hi -
I wanted to answer some of the survey questions about concurrency in SQLite.
Finer-grained locking would not help our particular application. We have a
multi-threaded application where there are many reader threads and a single
writer thread. It's not a big deal for us if the readers read un
It looks to me that several users are (a) in a uniprocess environment,
and (b) inventing their own SQLite db access synchronization code. An
SQLite fine grained lock manager for threads in a single process would
address these same issues, with better concurrency as well.
Jay said:
> All database a
G'day,
"D. Richard Hipp" <[EMAIL PROTECTED]>
24/11/2003 03:22 AM
To: [EMAIL PROTECTED]
cc:
Subject:[sqlite] Concurrency in SQLite
> Please, give me some examples of the kinds of things you are
> doing which could benefit from improved concurrency.
>
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
Hello,
On 11/23/03 6:22 PM, D. Richard Hipp wrote:
Lots of people seem to think that better concurrency in
SQLite would be useful. But I am having trouble understanding
why.
I have SQLite or Server systems. I would like not to make that
choice - soft option I mean. As you can read I'm useing "w
> Please, give me some examples of the kinds of things you are
> doing which could benefit from improved concurrency.
One typical application for me is data recording for regulatory
compliance (FDA 21 CFR 11). Instruments are polled or issue data
frequently, say once a second. Data from several of
My thoughts are that most programmers over use and abuse threading and I
love the simplicity of your database as it is. Can't tell you how many C
projects that have almost failed because of threading and memory issues (til
I took over them and became Mr. Fix man). First thing I did was pull out
a
Hi Richard,
On Sun, Nov 23, 2003 at 12:22:25PM -0500, D. Richard Hipp wrote:
> Lots of people seem to think that better concurrency in
> SQLite would be useful. But I am having trouble understanding
> why.
First, kind thanks for SQLite - it's a nice piece of work, and fits a project
I'm working
On Sun, 23 Nov 2003 12:22:25 -0500
"D. Richard Hipp" <[EMAIL PROTECTED]> wrote:
> Lots of people seem to think that better concurrency in
> SQLite would be useful. But I am having trouble understanding
> why.
I've only just caught onto this thread but I have to also ponder and agree... SQLite
i
11 matches
Mail list logo
