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
>
te.org
cc:
03/13/2005 09:33 Subject: [sqlite] Re:
[unclassified] Re: [sqlite] getting rid of
7 matches
Mail list logo