On Tue, Mar 15, 2005 at 01:24:51PM -0500, Ned Batchelder wrote:
> The best solution is to rollback entire transactions when the database is
> busy. This means structuring your code so that all transactions can
> rollback and retry. In my experience, this is necessary (though *far* less
>
> Regarding: ... As an example the ethernet card you're probably using
> right
> now.
> ... they detect the collision, wait a short period, and retry.
>
> For those using Unix/Linux, would this provide the queuing needed for
> those
> apps with numerous parallel writes?
>
t/clemensv/PermaLink,guid,826bc7c9-8b0f-4df6-aa
be-e6c5377a9446.aspx
--Ned.
-Original Message-
From: Andrew Piskorski [mailto:[EMAIL PROTECTED]
Sent: Monday, March 14, 2005 8:23 PM
To: sqlite-users@sqlite.org; [EMAIL PROTECTED]
Subject: Re: [sqlite] Re: [unclassified] Re: [sqlite] getting ri
Regarding: ... As an example the ethernet card you're probably using right
now.
... they detect the collision, wait a short period, and retry.
For those using Unix/Linux, would this provide the queuing needed for those
apps with numerous parallel writes?
> I have not tried this with SQLite, but if I was using SQLite for such
> an app, I assume I would need to serialize all such writes through a
> single thread or process. E.g., in my web server, the connection
> thread servicing the user request would send a message to my one
> single db writer
On Tue, Mar 15, 2005 at 12:21:15AM +0100, Thomas Lotterer wrote:
> On Sun, Mar 13, 2005, jed wrote:
>
> > [...] web applications fit well into the model of "many readers, one
> > writer", sqlite does this very well.
> >
> Well, there might be web applications which are read-only from the web's
>
On Sun, Mar 13, 2005, Jan-Eric Duden wrote:
> The issue 1159 was marked as "not_a_bug".
> So is there a misunderstanding?
>
Maybe. I tried hard to explain my point of view.
--
[EMAIL PROTECTED], Cable & Wireless
Re,
this solution rocks. Thanks a lot!
On Sun, Mar 13, 2005, D. Richard Hipp wrote:
> On Sun, 2005-03-13 at 16:49 -0500, D. Richard Hipp wrote:
> > On Sun, 2005-03-13 at 21:56 +0100, Thomas Lotterer wrote:
> >
> > > I cannot believe it is normal behavior of a database application
> > > running
[EMAIL PROTECTED] wrote:
Keep It Simple, Keep It Small Foot Print.
If the multi-access, multi writter can be implemented without compromising
these two tenets, then great. Otherwise, let's use a different RDBMS.
Jim Dodgen wrote:
Applications that need many concurrent tasks doing updates might
te.org
cc:
03/13/2005 09:33 Subject: [sqlite] Re:
[unclassified] Re: [sqlite] getting rid of
I like sqlite for it's simplicity in administration, small footprint, and
reliability, this coupled with a very robust implementation of SQL. a lot
embedded and web applications fit well into the model of "many readers, one
writer", sqlite does this very well. Applications that need many
On Sun, 2005-03-13 at 16:49 -0500, D. Richard Hipp wrote:
> On Sun, 2005-03-13 at 21:56 +0100, Thomas Lotterer wrote:
>
> > I cannot believe it is normal behavior of a database application running
> > on a multitasking operating system to assume there will only be one
> > writer and otherwise let
On Sun, 2005-03-13 at 21:56 +0100, Thomas Lotterer wrote:
> I cannot believe it is normal behavior of a database application running
> on a multitasking operating system to assume there will only be one
> writer and otherwise let the application fail or do retries by itself.
>
Believe it or
The issue 1159 was marked as "not_a_bug".
So is there a misunderstanding?
Thomas Lotterer wrote:
I've created an application that makes use of SQLite3. Occasionally,
multiple instances of that application run at the same time and need
to write to the database simultaneously. When I decided to use
I've created an application that makes use of SQLite3. Occasionally,
multiple instances of that application run at the same time and need
to write to the database simultaneously. When I decided to use SQLite
I was under the impression that the support for multiple writers doing
massive parallel
15 matches
Mail list logo
