Re: [sqlite] vers 3.0 concurrency issues
Christian Smith wrote: On Thu, 6 May 2004, Puneet Kishor wrote: Things that SQLite sucks at (if you pardon the expression) compared to Access and FMPro -- ALTERing tables is a royal pain in the behind. I am constantly in need of ALTERing the tables and queries (views) as I am developing the application, and to do this is just... well, not nice. I assume you have a copy of the source schema in a seperate file. All I do is: 1 Update source schema. 2 Compile schema into application. 3 Re-init the database using the new schema, having blown away the old database. If you have data you want to keep in step 3, write a migration tool to .. Thanks Christian, for the suggestions. However, I was not really looking for ways to do this. I already am able to do this somewhat similarly knowing what I know -- a Perl script that does it for me. What I was saying is that SQLite doesn't offer this capability within itself with a simple ALTER command. And that makes it cumbersome. That's all. Thanks anyway. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] vers 3.0 concurrency issues
On Thu, 6 May 2004, Puneet Kishor wrote:
>
>Things that SQLite sucks at (if you pardon the expression) compared to
>Access and FMPro -- ALTERing tables is a royal pain in the behind. I am
>constantly in need of ALTERing the tables and queries (views) as I am
>developing the application, and to do this is just... well, not nice.
I assume you have a copy of the source schema in a seperate file. All I do
is:
1 Update source schema.
2 Compile schema into application.
3 Re-init the database using the new schema, having blown away the old
database.
If you have data you want to keep in step 3, write a migration tool to
dump the data only to a text file of inserts (with named columns in the
inserts) and import the data again after the schema is updated. You could
update the SQLite shell to just output inserts in the correct format. All
it would need is an update to the callback() function in shell.c, to
output the column names in the insert. The following patch will do just
that (not extensively tested! Aginst 2.8.13.) Apply in the sqlite
directory with "patch -p1 < patch":
--- sqlite.old/src/shell.c 2004-02-25 02:25:37.0 +
+++ sqlite/src/shell.c 2004-05-07 16:49:51.0 +0100
@@ -387,7 +387,12 @@
}
case MODE_Insert: {
if( azArg==0 ) break;
- fprintf(p->out,"INSERT INTO %s VALUES(",p->zDestTable);
+ fprintf(p->out,"INSERT INTO %s(",p->zDestTable);
+ for(i=0; i0 ? ",": "";
+fprintf(p->out, "%s%s",zSep, azCol[i]);
+ }
+ fprintf(p->out,") VALUES(" );
for(i=0; i0 ? ",": "";
if( azArg[i]==0 ){
Richard, is there a reason why column names earn't listed when outputting
insert statements from the shell? If there is no reason, and noone finds
problems with the above code, could this go into the next release? Or
perhaps make it an option in the sqlite shell.
Cheers,
Christian
--
/"\
\ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] vers 3.0 concurrency issues
On Fri, May 07, 2004 at 09:22:59AM +0100, Paul Smith wrote: > Given that (IMHO) most concurrency problems seem to be centred around a > single application with multiple threads, might it not be possible for that > application to 'register' with SQLite in order to implement table locks. > Similarly for the tables. The application could do all the hard work in > this case. That sounds ok technically, but if I were the author and primary maintainer of SQLite, the first question I'd ask myself is, "Do I really want to have to sift through a bunch of bogus bug reports about SQLite corrupting data because the programmer implemented his table locking callbacks incorrectly?" I don't know how hard or easy it would be to do those callbacks right. If it's easy, that's probably fine. If it's NOT easy, I would worry about the above, and while worse for users who need the feature, for the maintainers, it might be better to not include that locking callback feature at all, or at least not to publicize it. Of course the MVCC designs batted around on this list would be better, but also, presumably, a lot more work. For that, Doug Currie's suggestion to "integrate the shadow paging ideas with BTree management" sounds like the best idea so far: http://www.mail-archive.com/[EMAIL PROTECTED]/msg01982.html -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] vers 3.0 concurrency issues
At 17:22 06/05/2004, D. Richard Hipp wrote: Thomas, Basil wrote: > I am no technical expert but...could not page locking at least be implemented > by the pager module to increase concurrency(very naive...but better than file > locking). > Page-level locking will not help. For one thing, we cannot do both page-level locking and reader/writer locks on win95/98/ME. Presumably, reader/writer locks are more desirable than page locks and we are not yet ready to abandon win95/98/ME. (You can do both on unix and winNT/2K/XP.) But more importantly, locking is less than half the problem. The hard part is not locking but recovering from a program crash or OS crash or power failure. If we didn't have to deal with crashes and power failures, doing page-level or row-level locking would be (relatively) easy. In version 3.0, you will be able to ATTACH multiple databases and update them all at once (and atomicially). Then if you put each of your tables in a separate database file and ATTACH them as needed, the end result will be something very like table-level locking. Without a central server process to coordinate things, getting any more concurrency than that is not a viable option, as far as I can determine. Given that (IMHO) most concurrency problems seem to be centred around a single application with multiple threads, might it not be possible for that application to 'register' with SQLite in order to implement table locks. So, my app says to SQLite 'register lock manager' Then SQLite says to my lock manager function: - lock database xyz.db for writing - lock table aa for writing - lock table bb for writing - unlock table bb - unlock table aa - unlock database xyz.db The application should put a file lock on the database when it gets the 'lock database' callback, so that other applications sharing the file can't write to it, but if another thread in the same application also does a 'lock database xyz.db', then it would just increment a reference count, not try to lock it again. Similarly for the tables. The application could do all the hard work in this case. If there was no callback registered, SQLite would act like it does now, with file level locks PaulVPOP3 - Internet Email Server/Gateway [EMAIL PROTECTED] http://www.pscs.co.uk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] vers 3.0 concurrency issues
Hold up there trigger, I didn't mean for everyone to launch into a blow by blow comparison of features between various RDBMS. My point was that in terms of concurrency, how does SQLite compare with other non-supervised databases technologies like JET (Access), Paradox etc. That way, any criticism of SQLite's shortcomings in this area can be fairly judged. On a more general point, I too am a SQLite zealot and have a great deal of admiration for Richard's work. However, I'm not blinkered into thinking that there aren't other technologies that may offer other features. It's often horses for courses, one solution never fits all in my experience. JET is probably the most prevalent relational database technology in the world today, thanks to it being used in projects ranging from school homework to foreign exchange management so it's a little glib to question whether the developers at MS "...have a clue". I'm not saying it's the best or fastest but it must have something going for it... Steve -Original Message- From: Puneet Kishor [mailto:[EMAIL PROTECTED] Sent: 06 May 2004 18:59 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [sqlite] vers 3.0 concurrency issues On May 6, 2004, at 12:24 PM, Steve O'Hara wrote: > I've been watching the discussion about concurrency with interest. I > find > I'm impressed by everybody's arguments. > > I'd too would like to keep SQLite small and fast but equally, I'd like > to > have better concurrency. Even if this is just a safeguard for the > future. > > However, I'm wondering why we're comparing SQLite with kernel based > RDBMS > like Oracle etc, and not with it's more closely related cousins such as > Access ? > > In this regard, how does SQLite compare with > Access/FoxPro/Paradox/dBase ? > I can comment on it from a user/appdeveloper's perspective -- a very subjective, my perpective. Things that SQLite can do that Access or FilemakerPro (two I have worked with) cannot do -- SQLite is fanstastically fast, supports transactions, and runs identically and equally happily on my Win box at work and iBook at home... no data conversion, no hassles. Things that SQLite sucks at (if you pardon the expression) compared to Access and FMPro -- ALTERing tables is a royal pain in the behind. I am constantly in need of ALTERing the tables and queries (views) as I am developing the application, and to do this is just... well, not nice. So... the real answer to "how does SQLite compare with ?" is "it depends." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] unsolved RDBMS problems Re: [sqlite] vers 3.0 concurrency issues
On Thu, May 06, 2004 at 03:20:13PM -0400, Andrew Piskorski wrote: > - User defined types, aka good "object" support (Date's "Third > Manifesto"). > > - Native bi-temporal support, or even just good support for one of > valid-time or transaction-time (Snodgrass). This one in particular I > would defnitely have used if it was available. (This is probably > related to supporting other dimensions well, like time.) See also: [Oops, that parenthetical comment about "other dimensions" belonged in the first bullet point further above about type extensability, not in the second one on bi-temporal support.] -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] unsolved RDBMS problems Re: [sqlite] vers 3.0 concurrency issues
On Thu, May 06, 2004 at 01:21:28PM -0500, Puneet Kishor wrote: > Frankly, I am not sure if there is anything exciting left in relational > databases to discover or create... most has been created and > well-tested over the past 3 decades. What is left is making a tool No way, that is not true! Certainly both C.J. Date and Rick Snodgrass would both vehemently disagree, although probably for different reasons. Some concrete examples: - User defined types, aka good "object" support (Date's "Third Manifesto"). - Native bi-temporal support, or even just good support for one of valid-time or transaction-time (Snodgrass). This one in particular I would defnitely have used if it was available. (This is probably related to supporting other dimensions well, like time.) See also: http://openacs.org/forums/message-view?message_id=105737 - Schema version control! CVS does an adequate job of automatically diffing and merging text files, but leaves lots of room for improvement (witness BitKeeper, Arch, all the commercial systems, etc.). AFAIK there is *NO* even CVS-level tool available for versioning and converting relational schemas ** which contain data **. If your database is empty, changing your schema is trivial. If it is full of data, making non-trivial modifications to your schema can quickly become very, very obnoxious. My guess is that 80% of the schema upgrade effort is automatable, but it has not been automated. (It can't be fully automated because when altering tables and re-factoring data, the schema patch tool can't always know where you wan tthe data to move from/to, an you the programmer need to tell explicitly tell it.) (I think I heard that Toad may help somewhat with that sort of thing for Oracle, but I never looked into it.) - Replication, scalability. It sure would be nice to just run a big huge RDBMS on a bunch of cheap 1U Linux boxes rather than a single big expensive SMP box, and just rack and stack a few more 1U boxes each time your database or user load gets bigger. Depending who you ask, this seems to currently either be not feasible at all, or so complicated and with such poor scalability that hardly anyone even tries it. See also: http://openacs.org/forums/message-view?message_id=128060 There are probably many other examples of significant unsolved RDBMS problems, too. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] vers 3.0 concurrency issues
On May 6, 2004, at 2:06 PM, Andrew Piskorski wrote: On Thu, May 06, 2004 at 01:21:28PM -0500, Puneet Kishor wrote: they are as real a database as one wants them to be. Sure, they don't support ACID compliance, but I am not sure if they are created by Ugh, that particular argument is one I should not have started. My apologies to all, and let's just let that one lie. ;-). No problem. I have recently created a pretty useful app for a client using Perl/DBI, DBD-ODBC and Access. Given how fluid the design was throughout the development, I simply could not have done so with SQLite because of the lack of an ALTER command. What makes you so dependent on "alter table" in your development? .. Is that the situation you find yourself in? I.e., you are not developing something new from scratch, but are making extensive changes to an already system already in heavy Production use? yup and yup... I am developing something new from scratch, and I then I am making extensive changes to the system developed by me and already in use. In this particular case, as the app developed, the client came up with new ideas, functionality... par for course. Which meant going in and changing column names, types, widths, etc. Access made it really easy... clickety-click. done. Some of it may have been easy with Oracle as well... but not because of Oracle but because of TOAD. Same with SQL Server... it is the Enterprise Mgr that makes it easy. So, going back to my argument -- the real-ness of a db is the composite of its database-ness and its ease-of-use-ness. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] vers 3.0 concurrency issues
On Thu, May 06, 2004 at 01:21:28PM -0500, Puneet Kishor wrote: > they are as real a database as one wants them to be. Sure, they don't > support ACID compliance, but I am not sure if they are created by Ugh, that particular argument is one I should not have started. My apologies to all, and let's just let that one lie. > I have recently created a pretty useful app for a client using > Perl/DBI, DBD-ODBC and Access. Given how fluid the design was > throughout the development, I simply could not have done so with > SQLite because of the lack of an ALTER command. What makes you so dependent on "alter table" in your development? I've done a lot of data modeling work in Oracle, but have only rarely used "alter table" by choice. When I did use it, it was generally carefully tested upgrade scripts which I needed to apply to an existing instance already in Production. When loading test data into a Development instance, I would generally prefer to do that completely from scratch - run all my create scripts, then separately load data in. No alters involved. Hm, however, a different scenario is if you are copying data from Production to a Dev instance for development or testing purposes. In that case, dumping/exporting Production and loading everything right back verbatim into Dev is certainly the easiest way to go, and once you have that in Dev, you ARE going to want to use a lot of "alters"... Is that the situation you find yourself in? I.e., you are not developing something new from scratch, but are making extensive changes to an already system already in heavy Production use? The "export out of Prod, import into Dev", method has many advantages, especially for testing. Its drawback is that it's easy to quickly lose all ability to create your data model from scratch... Unfortunately there seems to be no way to have the best of both worlds. Either you put the extra effort into maintaining SEPARATE create scripts and upgrade scripts, or you lose the ability to do one or the other at all. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] vers 3.0 concurrency issues
In the spirit of discussion -- On May 6, 2004, at 1:08 PM, Andrew Piskorski wrote: On Thu, May 06, 2004 at 06:24:10PM +0100, Steve O'Hara wrote: However, I'm wondering why we're comparing SQLite with kernel based RDBMS like Oracle etc, and not with it's more closely related cousins such as Access ? In my case, because I am very familiar with Oracle, somewhat less so with PostgreSQL, and much less familiar with most other databases. Also, because databases like Oracle and PostgreSQL are the current gold standard for functionality. Why compare to anything less? comparing SQLite with Oracle and Pg because one is familiar with the latter two is a valid reason. But, not comparing it to anything else is not very useful either. In this regard, how does SQLite compare with Access/FoxPro/Paradox/dBase ? Because none of those are Real Databases? ;) [Joking, joking...] Well, MOSTLY joking. Actually, I've no idea to what extent those each qualify as "Real Databases" (aka, full ACIDity, featureful, designed and implented by folks who have a clue, etc.). However, I am reasonably sure that they're neither as powerful as PostgreSQL nor as small and simple as SQLite, and that none of them are Open Source. Therefore, they are not particularly interesting - not to me anyway. they are as real a database as one wants them to be. Sure, they don't support ACID compliance, but I am not sure if they are created by people who don't have a clue. I have done some very useful, productive, and paying work with Access, and so have I with Oracle and SQLServer. Frankly, till now I have not done any paying work with SQLite, but definitely some useful and creative work. As much as I detest M$, and as much as I love opensource, I have credit M$ for making fairly decent databases for both desktop and client/server use at a reasonable price (compared to Oracle and DB2 anyway). SQLite can't be compared favorably with Oracle/Pg because it doesn't pretend to be a client-server db. However, either one decides that SQLite is _only_ for embedded apps, or SQLite won't compare very favorably with the "not-real databases" as well because the "not-real databases" are indeed very easy to use and rapidly develop apps with. I have recently created a pretty useful app for a client using Perl/DBI, DBD-ODBC and Access. Given how fluid the design was throughout the development, I simply could not have done so with SQLite because of the lack of an ALTER command. So, personally, I couldn't give a hoot about ?-level locking or concurrency, but give my ESC key for an ALTER command. Others will obviously think differently. Access/FMPro/Paradox may not be opensource, but so is not Oracle, so by that reasoning, even Oracle should be out when it comes to comparison. Frankly, I am not sure if there is anything exciting left in relational databases to discover or create... most has been created and well-tested over the past 3 decades. What is left is making a tool useful. And "useful" is a composite of "capability" and "ease of use." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] vers 3.0 concurrency issues
On Thu, May 06, 2004 at 06:24:10PM +0100, Steve O'Hara wrote: > However, I'm wondering why we're comparing SQLite with kernel based RDBMS > like Oracle etc, and not with it's more closely related cousins such as > Access ? In my case, because I am very familiar with Oracle, somewhat less so with PostgreSQL, and much less familiar with most other databases. Also, because databases like Oracle and PostgreSQL are the current gold standard for functionality. Why compare to anything less? > In this regard, how does SQLite compare with Access/FoxPro/Paradox/dBase ? Because none of those are Real Databases? ;) [Joking, joking...] Well, MOSTLY joking. Actually, I've no idea to what extent those each qualify as "Real Databases" (aka, full ACIDity, featureful, designed and implented by folks who have a clue, etc.). However, I am reasonably sure that they're neither as powerful as PostgreSQL nor as small and simple as SQLite, and that none of them are Open Source. Therefore, they are not particularly interesting - not to me anyway. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] vers 3.0 concurrency issues
On May 6, 2004, at 12:24 PM, Steve O'Hara wrote: I've been watching the discussion about concurrency with interest. I find I'm impressed by everybody's arguments. I'd too would like to keep SQLite small and fast but equally, I'd like to have better concurrency. Even if this is just a safeguard for the future. However, I'm wondering why we're comparing SQLite with kernel based RDBMS like Oracle etc, and not with it's more closely related cousins such as Access ? In this regard, how does SQLite compare with Access/FoxPro/Paradox/dBase ? I can comment on it from a user/appdeveloper's perspective -- a very subjective, my perpective. Things that SQLite can do that Access or FilemakerPro (two I have worked with) cannot do -- SQLite is fanstastically fast, supports transactions, and runs identically and equally happily on my Win box at work and iBook at home... no data conversion, no hassles. Things that SQLite sucks at (if you pardon the expression) compared to Access and FMPro -- ALTERing tables is a royal pain in the behind. I am constantly in need of ALTERing the tables and queries (views) as I am developing the application, and to do this is just... well, not nice. So... the real answer to "how does SQLite compare with ?" is "it depends." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] vers 3.0 concurrency issues
top posting... views of another "arm-chair critic/desirer of features" follow -- I too, like Basil Thomas, like Andrew's writeup. Well-reasoned. Like it or not... all programs start simple and evolve to a level unsupportable complicatedness until the developer's either lose interest or the program gets bought out by Microsoft. We use SQLite because we like it. The more we use it, the more we will run into "one more thing that, if it could do, would be so great" problem. Introducing that capability will make SQLite that much more useful, and that much more complicated, hence different from what attracted us to it. But, hey... there is no way out of it. If I am using SQLite, and it works great, it would be a shame to abandon it just because it can't or won't do that one thing that I want it to do. SQLite is really wonderful, and fast as all heck (yesterday I ran comparative tests against SQLite, Access, SQL Server, and Berkeley DB... SQLite blew all the relational dbs out of the water... it was only beaten by Bdb -- I guess there is nothing faster than in-memory manipulation of hash tables). But, I do miss some simple things such as ALTER table command, some not-so-simple things such as row-level locking, and am puzzled by some (IMO) quirky things such as croaking on parens (ref. my recent posts on this subject) or not auto-aliasing table.columnnames as columnnames... Well, that's it. The better SQLite gets, the more folks will use it, and the more folks will use it, the more different uses/conditions they will use it in, and the more they do that, the more new features they will desire. Everything rises in complexity until it collapses. Until then, lets enjoy the ride. On May 6, 2004, at 12:22 PM, [EMAIL PROTECTED] wrote: 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 ava
RE: [sqlite] vers 3.0 concurrency issues
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.
RE: [sqlite] vers 3.0 concurrency issues
I've been watching the discussion about concurrency with interest. I find I'm impressed by everybody's arguments. I'd too would like to keep SQLite small and fast but equally, I'd like to have better concurrency. Even if this is just a safeguard for the future. However, I'm wondering why we're comparing SQLite with kernel based RDBMS like Oracle etc, and not with it's more closely related cousins such as Access ? In this regard, how does SQLite compare with Access/FoxPro/Paradox/dBase ? Steve -Original Message- From: Andrew Piskorski [mailto:[EMAIL PROTECTED] Sent: 06 May 2004 17:53 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] vers 3.0 concurrency issues
Thanx The main reason for file locking is to support win95/98/ME???... I do have a server process running and have embedded sqlite to be used by individual threads that may be started. All writes currently go to one writer thread and this seems to work fine. The application we have developed basically creates a virtual xml storage using SQLite as the backing store. When documents are small, transactions do not slow concurrency that much but once in a while we may import a large document or update many small documents at once, we have noticed a large decrease in concurrency as all reader threads are blocked until the write thread that is in a transaction completes. One way we have gotten around this is to implement multiple collections of documents with each collection stored in one database. Implementing each virtual document as a single file/db is out of the question as we have thousands of documents stored already in each collection. All the other features in SQLite are too good for me to abandon just for lack of higher concurrency. Since I have read a lot of suggestions to improve concurrency for ver 3.0, can you tell me what will be changed if anything in version 3.0 as regards increased concurrency??? -Original Message- From: D. Richard Hipp [mailto:[EMAIL PROTECTED] Sent: Thursday, May 06, 2004 12:23 PM To: [EMAIL PROTECTED] Subject: Re: [sqlite] vers 3.0 concurrency issues Thomas, Basil wrote: > I am no technical expert but...could not page locking at least be implemented > by the pager module to increase concurrency(very naive...but better than file > locking). > Page-level locking will not help. For one thing, we cannot do both page-level locking and reader/writer locks on win95/98/ME. Presumably, reader/writer locks are more desirable than page locks and we are not yet ready to abandon win95/98/ME. (You can do both on unix and winNT/2K/XP.) But more importantly, locking is less than half the problem. The hard part is not locking but recovering from a program crash or OS crash or power failure. If we didn't have to deal with crashes and power failures, doing page-level or row-level locking would be (relatively) easy. In version 3.0, you will be able to ATTACH multiple databases and update them all at once (and atomicially). Then if you put each of your tables in a separate database file and ATTACH them as needed, the end result will be something very like table-level locking. Without a central server process to coordinate things, getting any more concurrency than that is not a viable option, as far as I can determine. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - 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.
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]
RE: [sqlite] vers 3.0 concurrency issues
On Thu, 6 May 2004, Thomas, Basil wrote: >I have already implemented a solution using the application using MS SQL >Server/Sybase and >SQLite is at least a hundred times faster. The problem is when implementing >"long" transactions. Can you not implement batching of writes into single small transactions? Why do you need "long" transactions? >When there is only a maximum of one user/thread, there are no long >transactions as a transaction can take as long as it likes. Transaction >length is only a problem as more users concurrently use the database. >I am not looking for a perfect solution as SQLite is great already, just >higher concurrency. >I am no technical expert but...could not page locking at least be >implemented by the pager module to increase concurrency(very naive...but >better than file locking). There has been discussion of essentially using snapshots to support concurrent readers/writer (readers take a snapshot from before the writer started.) That way, a writer will not affect the operation of readers, but this is will be a 3.0 at the very earliest, if at all. Not sure how DRH is getting on with that. A suggested solution is documented here: http://www.sqlite.org/cvstrac/wiki?p=BlueSky Christian > > >-Original Message- >From: Christian Smith [mailto:[EMAIL PROTECTED] >Sent: Thursday, May 06, 2004 9:38 AM >To: Thomas, Basil >Cc: [EMAIL PROTECTED] >Subject: Re: [sqlite] vers 3.0 concurrency issues > > >On Thu, 6 May 2004 [EMAIL PROTECTED] wrote: > >> >>I would like to use SQLite on a web server or .net remoting and >>multi-user/threads may become an issue >>as locking is based at the finest granularity of file locking instead of >>table/page/row locking. Will this issue be resolved from 3.x onwards so >that >>concurrency can be increased when multiple users >>are connecting to the db? >>SQLite is extremely fast in single process/thread mode and because of this >>success, more users would like to access the application. File locking is >>too similar to MS Access and we have had all kinds of problems >>supporting multiple users on a network drive. Ideally I would first like to >>implement SQLite as part of an ISAPI dll so it could be accessed using http >>to an IIS web server. >>Any suggestions or solutions to running SQLite in multi-threaded >environment >>with potentially high concurrency??? > >SQLite already supports concurrent readers. If most access is read only, >and writes are short and/or infrequent, then SQLite might continue to fit >the bill. > >But, use the right tool for the job. If you require concurrent >readers/writer(s), then you may be better off using a full blown >client/server database, especially in a distributed environment. SQLite is >designed to be embedded, don't just use it because you can. > >I believe there may be some work in 3.0 to allow concurrent readers with >single writer, but that is likely to be within a single address space >only, if at all. > > >>B.Thomas >> >>-Original Message- >>From: D. Richard Hipp [mailto:[EMAIL PROTECTED] >>Sent: Tuesday, May 04, 2004 1:56 PM >>To: [EMAIL PROTECTED] >>Subject: Re: [sqlite] release 14 >> >> >>aducom wrote: >>> Hi, >>> >>> Is it possible to do a release 14 of the sqlite.dll with the support of >>> real blobs? (It's available in cvs?) Or will I have to wait for the >>> full new version? >>> >> >>I don't know what you mean by "support for real blobs". You'll need >>to be much more specific. >> >>Generally speaking, no new features will be added to SQLite 2.8.13. >>What you see is what you get. New features go into SQLite 3.0.0. >> > > -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: [sqlite] vers 3.0 concurrency issues
I'm testing sqlite on a network (Windows 2003 Server) share and with 5 users. I've created a "server" program which is ran from the same directory as the shared database. The program that the 5 users have, will read only from the sqlite database in that directory. Whenever they want to add a new record, I create the record in XML format and send it as a file to the shared directory. The server program is watching the directory for the xml file(s)...when one is "posted", it reads it in and writes to the database. Thus I have only 1 program writing to the sqlite database at any one time. This environment is in testing and so far so good. Not one problem. The reads are very fast and using the xml/server program, the writes are fine (so far). I would like to create a synchronizer at some point in the future. Sorta replication to users local sqlite database reading from the server central data store (or something similar). Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] vers 3.0 concurrency issues
Thomas, Basil wrote: > I am no technical expert but...could not page locking at least be implemented > by the pager module to increase concurrency(very naive...but better than file > locking). > Page-level locking will not help. For one thing, we cannot do both page-level locking and reader/writer locks on win95/98/ME. Presumably, reader/writer locks are more desirable than page locks and we are not yet ready to abandon win95/98/ME. (You can do both on unix and winNT/2K/XP.) But more importantly, locking is less than half the problem. The hard part is not locking but recovering from a program crash or OS crash or power failure. If we didn't have to deal with crashes and power failures, doing page-level or row-level locking would be (relatively) easy. In version 3.0, you will be able to ATTACH multiple databases and update them all at once (and atomicially). Then if you put each of your tables in a separate database file and ATTACH them as needed, the end result will be something very like table-level locking. Without a central server process to coordinate things, getting any more concurrency than that is not a viable option, as far as I can determine. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] vers 3.0 concurrency issues
> > [U]se the right tool for the job. If you require concurrent > > readers/writer(s), then you may be better off using a full blown > > client/server database, especially in a distributed > environment. SQLite is > > designed to be embedded, don't just use it because you can. > > > > 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. > SQLite does not try to be the solution to every database > problem - it is primarily an embedded database. I don't think that concurrency is an unlikely requirement for an embedded database. Consider an application that uses SQLite for its internal database, and an external reporting tool like Crystal Reports. Crystal Reports uses ODBC, so although it may be a single user application, there is still a need for concurrency because you never know when the user will try to run a report. If they do it which some other long-running query is executing in the application then the report fails when one of the queries times out. It seems to me that the file based sharing in SQLite is an admission that concurrency is necessary, it just isn't a very robust solution. Don't get me wrong here. I think that SQLite is fantastic, and is extremely well designed and implemented in every respect, except for the support for concurrency. > SQLite does not try to be the solution to every database problem... If there was better concurrency supprt in SQLite it seems to me that it would be the solution to many more database problems than it is today, without significantly impacting the existing feature set. In fact for most applications things would probably go faster if the need to carefully use transactions to avoid the file closing overhead. I understand that being free, SQLite is at the whim of the people who actually contribute to the code base. Unfortunately I don't have the database knowledge to specify a good concurrency solution, but I do have the skill to implement it, or could pay someone else to implement it. Regards, Chris. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] vers 3.0 concurrency issues
Christian Smith wrote: > > [U]se the right tool for the job. If you require concurrent > readers/writer(s), then you may be better off using a full blown > client/server database, especially in a distributed environment. SQLite is > designed to be embedded, don't just use it because you can. > 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. SQLite does not try to be the solution to every database problem - it is primarily an embedded database. See http://www.sqlite.org/cvstrac/wiki?p=WhenToUseSqlite -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] vers 3.0 concurrency issues
I am using SQLite expressly because of its type less data schema and large text field support. The application we have developed is using SQLite exactly as an embedded database and would require an extremely large re-write because of all the good features included in SQLite. The ONLY feature missing is "higher" concurrency when using transactions. I have already implemented a solution using the application using MS SQL Server/Sybase and SQLite is at least a hundred times faster. The problem is when implementing "long" transactions. When there is only a maximum of one user/thread, there are no long transactions as a transaction can take as long as it likes. Transaction length is only a problem as more users concurrently use the database. I am not looking for a perfect solution as SQLite is great already, just higher concurrency. I am no technical expert but...could not page locking at least be implemented by the pager module to increase concurrency(very naive...but better than file locking). -Original Message- From: Christian Smith [mailto:[EMAIL PROTECTED] Sent: Thursday, May 06, 2004 9:38 AM To: Thomas, Basil Cc: [EMAIL PROTECTED] Subject: Re: [sqlite] vers 3.0 concurrency issues On Thu, 6 May 2004 [EMAIL PROTECTED] wrote: > >I would like to use SQLite on a web server or .net remoting and >multi-user/threads may become an issue >as locking is based at the finest granularity of file locking instead of >table/page/row locking. Will this issue be resolved from 3.x onwards so that >concurrency can be increased when multiple users >are connecting to the db? >SQLite is extremely fast in single process/thread mode and because of this >success, more users would like to access the application. File locking is >too similar to MS Access and we have had all kinds of problems >supporting multiple users on a network drive. Ideally I would first like to >implement SQLite as part of an ISAPI dll so it could be accessed using http >to an IIS web server. >Any suggestions or solutions to running SQLite in multi-threaded environment >with potentially high concurrency??? SQLite already supports concurrent readers. If most access is read only, and writes are short and/or infrequent, then SQLite might continue to fit the bill. But, use the right tool for the job. If you require concurrent readers/writer(s), then you may be better off using a full blown client/server database, especially in a distributed environment. SQLite is designed to be embedded, don't just use it because you can. I believe there may be some work in 3.0 to allow concurrent readers with single writer, but that is likely to be within a single address space only, if at all. >B.Thomas > >-Original Message- >From: D. Richard Hipp [mailto:[EMAIL PROTECTED] >Sent: Tuesday, May 04, 2004 1:56 PM >To: [EMAIL PROTECTED] >Subject: Re: [sqlite] release 14 > > >aducom wrote: >> Hi, >> >> Is it possible to do a release 14 of the sqlite.dll with the support of >> real blobs? (It's available in cvs?) Or will I have to wait for the >> full new version? >> > >I don't know what you mean by "support for real blobs". You'll need >to be much more specific. > >Generally speaking, no new features will be added to SQLite 2.8.13. >What you see is what you get. New features go into SQLite 3.0.0. > -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \ 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.
RE: [sqlite] vers 3.0 concurrency issues
With the pending 3.0, I think we are at a juncture so to speak. We all like/use SQLite because it is very lightweight, fast, and above all simple. One of the major reasons this is so, is due to the very limited and focused functionality. Once SQLite becomes more "functional" all of these appealing aspects will begin to fade away. There is a very good set of reasons why Oracle, SQL Server, and even MySQL are what they are and SQLite is what it is. As users we must decide what it is we expect from SQLite and what "other" DB's might offer given our environment. We don't haul several hundred concrete blocks in a sports car (Well, some try to) that's what trucks are for. I'm not saying there is no room for improvement in SQLite's functionality, but I feel things need to be kept in perspective. There truly are times when a hammer simply will not drive a screw, and should not be attempted. Your results may vary... Fred > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 06, 2004 8:26 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [sqlite] vers 3.0 concurrency issues > > > > I would like to use SQLite on a web server or .net remoting and > multi-user/threads may become an issue > as locking is based at the finest granularity of file locking instead of > table/page/row locking. Will this issue be resolved from 3.x > onwards so that > concurrency can be increased when multiple users > are connecting to the db? > SQLite is extremely fast in single process/thread mode and because of this > success, more users would like to access the application. File locking is > too similar to MS Access and we have had all kinds of problems > supporting multiple users on a network drive. Ideally I would > first like to > implement SQLite as part of an ISAPI dll so it could be accessed > using http > to an IIS web server. > Any suggestions or solutions to running SQLite in multi-threaded > environment > with potentially high concurrency??? > B.Thomas > > -Original Message- > From: D. Richard Hipp [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 04, 2004 1:56 PM > To: [EMAIL PROTECTED] > Subject: Re: [sqlite] release 14 > > > aducom wrote: > > Hi, > > > > Is it possible to do a release 14 of the sqlite.dll with the support of > > real blobs? (It's available in cvs?) Or will I have to wait for the > > full new version? > > > > I don't know what you mean by "support for real blobs". You'll need > to be much more specific. > > Generally speaking, no new features will be added to SQLite 2.8.13. > What you see is what you get. New features go into SQLite 3.0.0. > -- > D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 > > > - > 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. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] vers 3.0 concurrency issues
On Thu, 6 May 2004 [EMAIL PROTECTED] wrote: > >I would like to use SQLite on a web server or .net remoting and >multi-user/threads may become an issue >as locking is based at the finest granularity of file locking instead of >table/page/row locking. Will this issue be resolved from 3.x onwards so that >concurrency can be increased when multiple users >are connecting to the db? >SQLite is extremely fast in single process/thread mode and because of this >success, more users would like to access the application. File locking is >too similar to MS Access and we have had all kinds of problems >supporting multiple users on a network drive. Ideally I would first like to >implement SQLite as part of an ISAPI dll so it could be accessed using http >to an IIS web server. >Any suggestions or solutions to running SQLite in multi-threaded environment >with potentially high concurrency??? SQLite already supports concurrent readers. If most access is read only, and writes are short and/or infrequent, then SQLite might continue to fit the bill. But, use the right tool for the job. If you require concurrent readers/writer(s), then you may be better off using a full blown client/server database, especially in a distributed environment. SQLite is designed to be embedded, don't just use it because you can. I believe there may be some work in 3.0 to allow concurrent readers with single writer, but that is likely to be within a single address space only, if at all. >B.Thomas > >-Original Message- >From: D. Richard Hipp [mailto:[EMAIL PROTECTED] >Sent: Tuesday, May 04, 2004 1:56 PM >To: [EMAIL PROTECTED] >Subject: Re: [sqlite] release 14 > > >aducom wrote: >> Hi, >> >> Is it possible to do a release 14 of the sqlite.dll with the support of >> real blobs? (It's available in cvs?) Or will I have to wait for the >> full new version? >> > >I don't know what you mean by "support for real blobs". You'll need >to be much more specific. > >Generally speaking, no new features will be added to SQLite 2.8.13. >What you see is what you get. New features go into SQLite 3.0.0. > -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
