On 9 Sep 2009, at 1:36am, Pavel Ivanov wrote:
>> Multiple processes has nothing to do with it, other than the usual
>> increases in complexity that would be added to any app.
>
> Except that it's much-much easier to implement fine-grained locks
> working inside one process, not dealing with file system locks and
> being sure that nobody but yourself will write to the database.
To the point where there are SQL systems that offer locking on the
record level, column level, and even field level. {shudder}
This is one of those things that get more complicated the longer you
look at it. For instance, there's no real difference between several
different applications (or even processes within one application)
using a database at the same time, and several different computers
talking to a database server at one time. If SQLite was to be
designed to handle multiple processes 'properly', it would have to be
rewritten as a client/server system.
This would, of course, kill all the advantages of SQLite: it could no
longer be tiny, fast, and ultra-portable. So it would be a bad design
choice for SQLite (bowing, of course, to DRH's right to do whatever he
pleases with it).
This is why I get uneasy when I see posts here that suggest spinning
off threads especially to deal with locking issues, or do other things
that solve concurrency or latency problems. Often you find that
making such a change in your program just leads to one of the threads
immediately being blocked by another, defeating the point of threading
in the first place. Software has to be designed around what is
possible with the tools you're using, not around some mythical idea of
the perfect generic SQL engine.
Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
