[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sqlite-users
Subject:    Re: [sqlite] Re: [unclassified] Re: [sqlite] getting rid of dirty SQLITE_BUSY workaround
From:       Thomas Lotterer <thl () dev ! de ! cw ! com>
Date:       2005-03-14 23:21:15
Message-ID: 20050314232115.GE77587 () dev ! de ! cw ! com
[Download RAW message or body]

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
view. But to be honest, most of them also call for occasional writes.
Think of a simple address book. Also I think of uses like tracking
session cookies which also use occasional writes. In all those cases
writes are triggered by the web user and we must never assume users will
arrange themselves and serialize their klicks. The more users you put on
a web server the more likely a collision will occur. Keep that in mind,
please.

> Applications that need many concurrent tasks doing updates might think
> about using a server based RDBMS that has the added complexity and
> size for this purpose.
> 
Agree. Massive parallel writers must say goodby to SQLite.

> It might me nice to have an option where you can have sqlite "wait
> forever" might be nice to implement as a pragma. the downside is that
> ... well things might wait for a very long time and appear to hang.
> 
Now we can have it all. See my happy result posting in this thread.

--
Thomas.Lotterer@cw.com, Cable & Wireless
[prev in list] [next in list] [prev in thread] [next in thread]