Yes, John, thanks very much. It seems absolutely clear by now that sharing data on a network mount by multiple web servers is not suitable for SQLite.
Funny, now that I say that I wonder how I couldn't see that from the beginning this was a worst case scenario. I guess I didn't know much about SQLite when I first posted and got excited about the design methodology. At least I understand SQLite a lot better now. Thanks again to everyone who posted in reply to my question. Take care guys and have fun. God bless. Anil -----Original Message----- From: John Stanton [mailto:[EMAIL PROTECTED] Sent: Monday, 5 February 2007 3:08 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Appropriate uses for SQLite We used Sqlite in a web server successfully. It is embedded in a custom written web server which provides multithreaded access and application language support (an application server). It handles many databases, with each user capable of having their own database. Synchronization is performed within the server. In our application Sqlite is an ideal solution and outperforms the alternative, using an IPC or network connection to PostgreSQL. The embedded nature of Sqlite gives us an advantage by minimizing network and disk traffic and avoiding repeated process creation and destruction. In your application my reaction would be to run PostgreSQL or similar (maybe the new free version of DB/2) on one of your servers and connect from the others. Anil Gulati -X (agulati - Michael Page at Cisco) wrote: > I have certainly got no desire to change the design goals of SQLite. > > The only reason I posted originally is because there was a strong > recommendation in the documentation to use it for web sites which of > course risk concurrent writes... The trouble introduced there in my > case is that I am using multiple web servers which therefore have to > share data over the network. > > FWIW I don't interpret any posts on this thread as an attempt to > change SQLite, either. But there seems to be some who see value in > more clearly defining *when* SQLite *does* work. I guess that there is > a lot of enthusiasm for SQLite's ability and performance and it's nice > to be able to prove that SQLite does actually compete in areas it was > not even designed for. Perhaps an argument for less complex design as > a generic software design strategy. > > -----Original Message----- > From: David M X Green [mailto:[EMAIL PROTECTED] > Sent: Sunday, 4 February 2007 1:17 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Appropriate uses for SQLite > > I am new to this but are these issues those of trying to get it to do > what sqlite it is not designed for. I quote the book > > The Definitive Guide to SQLite - Chapter 1 --- Networking " .... > Again, most of these limitations are intentional-they are a result of > SQLite's design. Supporting high write concurrency, for example, > brings with it great deal of complexity and this runs counter to > SQLite's simplicity in design. > Similarly, being an embedded database, SQLite intentionally does > __not__support__networking__ [my emphasis]. This should come as no > surprise. > In short, what SQLite can't do is a direct result of what it can. It > was designed to operate as a modular, simple, compact, and easy-to-use > embedded relational database whose code base is within the reach of > the programmers using it. And in many respects it can do what many > other databases cannot, such as run in embedded environments where > actual power consumption is a limiting factor. " > ------ > Is it really a good idea to network a data base that relies on the OS > file systems like this? Is it ever going to be safe enough? > -------------------- > David M X Green > > >>>>|||"Alex Roston" (2007-02-02 20:05) wrote: |||>>> >> >>Scott Hess wrote: >> >>>On 2/2/07, Dennis Cote <[EMAIL PROTECTED]> wrote: >>> >>>>[EMAIL PROTECTED] wrote: >>>> >>>>>The problem is, not many network filesystems work correctly. >>>> >>>>I'm sure someone knows which versions of NFS have working file >>>>locking, at least under Linux. >>> >>>I doubt it is this easy. You need to line up a bunch of things in >>>the right order, with the right versions of nfs, locking services, >>>perhaps the right kernel versions, the right config, etc, etc. >>> >>>IMO the _real_ solution would be a package which you could use to try > > >>>to verify whether the system you have is actually delivering working >>>file locking. Something like diskchecker (see >>>http://brad.livejournal.com/2116715.html). The basic idea would be >>>to have a set of networked processes exercising the APIs and looking >>>for discrepencies. Admittedly, passing such a test only gets you a >>>statistical assurance (maybe if you'd run the test for ten more >>>minutes, or with another gig of data, it would have failed!), but >>>failing such a test is a sure sign of a problem. >>> >>>-scott >> >>That's a really useful idea, not only for itself, but also because it >>might lead to debugging some of the network issues, and allowing the >>developers to build a database of stuff that works: "Use Samba version > > >>foo, with patch bar, and avoid the Fooberry 6 network cards." Or > > whatever. > >>My suspicion, in the earlier case with Windows and Linux clients is >>that Windows didn't handle the locking correctly, and that would be >>worth proving/disproving too. >> >>An alternate approach is to use something a little more like a >>standard client-server model, where there's a "server" program which >>intervenes between (possibly multiple) workstations and the database >>itself. The "server" would queue requests to the database, make sure >>that no more than one write request at a time went to the database, >>and certify that writes have been properly made. >> >>The problem with this approach is that it eats quite heavily into >>SQLite's speed advantage, but if you've already put thousands of hours > > >>into developing your system, it might be a worthwhile hack. >> >>Alex >> >>---------------------------------------------------------------------- >>------- >> >>To unsubscribe, send email to [EMAIL PROTECTED] >>---------------------------------------------------------------------- >>------- >> >> >> > > > > > ---------------------------------------------------------------------- > -- > ----- > To unsubscribe, send email to [EMAIL PROTECTED] > ---------------------------------------------------------------------- > -- > ----- > > ---------------------------------------------------------------------- > ------- To unsubscribe, send email to > [EMAIL PROTECTED] > ---------------------------------------------------------------------- > ------- > ------------------------------------------------------------------------ ----- To unsubscribe, send email to [EMAIL PROTECTED] ------------------------------------------------------------------------ ----- ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
