On 16.08.2013 18:03, Gary Weaver wrote:
Thanks to you and Richard for the links and info. Concurrency is not outlandish
to expect, especially when it works in OS X and just not in the Ubuntu vm in
Travis, but I now understand that these are expected problems.
_______________________________________________
You're right concurrency is not outlandish but from the viewpoint of
sqlite it was therefore this answer and the link.
On the other side most database systems also use serialized access to
the underlying filesystem while always exclusivly locking the whole
file, disk aso. The magic behind concurrently accessing the database in
those systems is to provide a client/server level where only the server
process has real access to the underlying physical storage while the
clients only have concurrent access to the server as a process. The fact
that most filesystem implementations especialy the network file
protocols are buggy and locking methods on OS es have those many
problems is proof enough that you need a client server modell if you
really want to support concurrent access. Sqlite on the other side is
for most applications a database engine library and an appreciated way
to access large amounts of data in a flexible way.
Concurrency is not outlandish but I for myself prefer that sqlite is a
simple library which at least assures that many applications trying to
access the same file can do this in a serialized way without corrupting
the file. And thats not a simple thing to achieve and get freely.
If you are interested on client server protocols wrapped around sqlite
there are a few and even contributed on the website.
It was not my intention to blame your statement but it was surprising to
hear it for sqlite.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
