-----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Simon Slavin Sent: Monday, September 21, 2009 3:05 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Most wanted features of SQLite ?
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. With "optional" fine grained locking would SQLite not work as the "back end" for a client server (wrapper) implementation that did the multi process (or whatever) lock management up one level so to speak? Sybase bought a small DB company a while back. The company was known as "Advantage DB" prior to the acquisition. They, and Sybase still does I believe, offered a "Local" and "Server" implementation of their DB. That is what I'm really thinking of here, with SQLite.dll used as the "Local" and SQLite.dll + ???? as the "Server." Fact is Advantage was what I was using for my "Local" DB implementations before discovering SQLite. Fred _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
