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
> 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
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
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
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
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
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
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.
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,
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
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
[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
-- 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
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.
>
14 matches
Mail list logo
