On 21 Sep 2009, at 6:53pm, Brad House wrote: > I definitely don't agree here as we're talking about these additional > locks existing _only_ in memory, not on disk.
Which requires client/server architecture. Which SQLite3 doesn't have. Once you require concurrent access features in your DBMS (i.e. multi-user, lots of locking) the things you nned to implement start to be easier with a client/server architecture, whether it's a standalone client application that must be launched manually or just a unix-style daemon running in the background which is launched automatically when needed and quits when nothing has used it in a while. On 21 Sep 2009, at 6:44pm, Pavel Ivanov wrote: > Interesting point, Simon. Are you saying that all developers of big > database engines that implemented row-level locks are just idiots > because there's no benefit from it at all? They had to implement just > database-level locks and all users would be a lot happier because > they'd received a significant performance boost? Nope. They chose to implement a big database engine and that meant they chose client/server architecture, which makes locking (and all other things that require centralised control) less difficult. It's just that this is not how SQLite works. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
