I really like this answer!!! The Goldilocks approach to increased concurrency... Hopefully DRH will read your answer and conclude this would be a good approach as the current take it or leave it answers are no help. Abandoning SQLite COMPLETELY for higher concurrency does not make sense but a third solution for medium ground between the two current extreme views to SQLite concurrency would be much appreciated. I wish I could work on this locking solution but my hands are tied because SQLite currently runs quite well in our current application and therefore many more features have been requested...such as supporting more users!!!
-----Original Message----- From: Andrew Piskorski [mailto:[EMAIL PROTECTED] Sent: Thursday, May 06, 2004 12:53 PM To: [EMAIL PROTECTED] Subject: Re: [sqlite] vers 3.0 concurrency issues On Thu, May 06, 2004 at 09:54:24AM -0400, D. Richard Hipp wrote: > Concurrency is not nearly as much an issue in reality > as it is in many peoples imagination. Concurrency > probably is not an issue for a website. If concurrency > really is an issue, you need a client/server database. While that might be true [I take no position on whether it is or not], to some real extent it may also be irrelevent. Here's my theory: People often don't know ahead of time, and aren't able to reasonably predict, just how much concurrency they will need. Also, their concurrency needs may change over time, again in ways that are hard for them to predict. Therefore, picking a tool which they KNOW has serious concurrency limitations introduces a significant risk, the risk that they may have to drastically overhaul their underlying tools and architecture at some unknown point in the future, due to hitting concurrency problems and thus suddenly discovering that they're now using the wrong tool for the job. Since SQLite's concurrency support is very limited, potential users are forced to pre-maturely optimize: Either believe you will need high concurrency, and go with PostgreSQL or Oracle, or believe you will need no or low concurrency, and go with SQLite. Premature optimization is a bad thing. There is a missing middle ground there: A medium-concurrency SQLite. If a future version of SQLite - let's call it "SQLiteMC" - were able to significantly increase concurrency, while at the same time preserving all or most of SQLite's historical advantages (simplicity, etc.), this would significantly expand the problem domain to which SQLite is applicable. That, in turn, would reduce the "wrong tool" risk of using SQLite, and both of those effects would tend to make SQLiteMC both more useful and more widely used than SQLite is now. That's my little mental model anyway. To me the direction of those effects seems just about certain, but what I don't know - and can't know, much less quantify - is the size of those effects - they could be anywhere from zero to large. And of course, that's assuming that SQLiteMC succeeds in its technical goals. And would SQLiteMC succeed in its technical goals? How hard would it be, and are there sufficient programmer resources available to make it happen? That I don't really know either, but together, Dr. Hipp plus a few other experts on this list could probably come up with a reasonably good idea... -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ------------------------------------------------------------This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen. ============================================================
