Thank you all so much for your data. It will really help me a lot.
Looks like I'll be able to use SQLite in ways I had originally
anticipated would be out of scope. Well done
On Mon, 2003-11-24 at 09:06, D. Richard Hipp wrote:
> D. Richard Hipp wrote:
> >
> > Over the past 30 days, the www.
> 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
I remember someone talking about something that could
be changed at compile time to prevent other sqlite
DLLs from seeing the database file as valid.. I tried
to find the original message but wasn't able to.. Can
someone clue me in?
I know it wont offer a whole lot of protection but I'm
just want
Bert and I have exchanged emails on this privately and the resolution is
that he actually *WAS* subscribed twice to the list. And so in an odd
way, everyone was correct: he *was* getting two copies of everything, but
the listserver was not misconfigured or misbehaving.
I'll re-extend my origin
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
> More data:
>
> I duplicated the www.sqlite.org website on my desktop then started
> hammering on it using multiple instances of "wget -r". I ran the
> test for several minutes.
>
> During this test, every hit involved multiple SELECTs and at least
> one UPDATE against a single sqlite database fi
Richard Heyes wrote:
During this test, every hit involved multiple SELECTs and at least
one UPDATE against a single sqlite database file. The database engine
was easily able to handle a rate of over 250 (2.5M) hits/day or
about 30 hits/second. The database did not appear to be the limiting
fa
> During this test, every hit involved multiple SELECTs and at least
> one UPDATE against a single sqlite database file. The database engine
> was easily able to handle a rate of over 250 (2.5M) hits/day or
> about 30 hits/second. The database did not appear to be the limiting
> factor in thi
D. Richard Hipp wrote:
Over the past 30 days, the www.sqlite.org website has seen 6
separate 10-minute bursts of activity with 25 hits/day rates
and many 1-minute bursts in the 45 hits/day range. Rates in
excess of 20 hits/day have been sustained for a couple of
hours on one event. (M
OK, Sqlite will scale just as well on a single processor machine with few
drives as any big RDBMS. If Sqlite was to take a turn to compete in areas
it does not already dominate clearly, it would be in scale. If sqlite could
take advantage of multiple processors and drives that would be huge, but
D. Richard Hipp wrote:
The www.sqlite.org website is run off of a single SQLite database.
Back before I implemented bandwidth throttling, the site would
sometimes get 5 hits/day to pages that used the database.
Over the past 30 days, the www.sqlite.org website has seen 6
separate 10-minute burs
Vania Smrkovski wrote:
Have you or anyone encountered issues regarding my other questions,
that of using SQLite as a web-served DB system? How do the recently
discussed issues of concurrency and the locking of DB tables and files
affect the use of a web site delivered SQLite DB system, and is the
Darren,
Thanks for the response. I knew about this issue as a security hole,
which is why one of my options was to place the DB files out of the
entire web doc tree. Happily, you took something that I had to learn
the hard way from tech notes and experience and codified it in a way
that c
[EMAIL PROTECTED] wrote:
[DQL statements ("SELECT ...") lock the whole database when using PySQLite.]
Hi,
I've thought about this whole issue and made a few changes to my local
working copy of PySQLite over the weekend, which will go into the next
release (during the next days):
The most import
-- Initial Header ---
>From : "Gerhard Häring" [EMAIL PROTECTED]
To : "sqlite-users" [EMAIL PROTECTED]
Cc :
Date : Fri, 21 Nov 2003 16:43:26 +0100
Subject : Re: [sqlite] database is locked
> [EMAIL PROTECTED] wrote:
> > Hi all,
> >
> > I'm trying SQLite
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.
>
18 matches
Mail list logo