"This is incorrect. Readers must wait when a page (the usual locking granularity AFAIK) is write locked or they could use data that is later rolled back. That would be an unrepeatable read and is bad."
Sorry, I am absolutely correct. Readers don't see the uncommitted data being written by another transaction, but rather previously committed data, and therefore aren't blocked by writers. It's all done on a row-level locking basis. Postgres and Interbase implement a very similar tuple-storing scheme which makes this (relatively) easy. This scheme is expensive in space, though - in Postgres, at least, you have to manually garbage collect your database with "vacuum" to reclaim space occupied by obsolete tuples. I run it automatically once a night.
Rollback doesn't affect committed data - read the definition of "commit" in any text on transaction processing if you don't understand.
I might be slightly wrong about Oracle, it may block readers of rows being written, anyone know for sure? I know this isn't true for Postgres, though - I've read the source. Writers don't block readers.
You are right that many commercial dbs do lock on a page basis. You are wrong in insisting that all do, and that row-level locking can not implement transaction semantics.
Those of us who support Open Source should be pleased that we have TWO Open Source databases that support write-locking on a row-level rather than block level basis, and that both never block readers when writing.
Postgres was slow for single users on one large benchmark run by PC Week. It's not been investigated thus far. I have some personal theories, though.
Postgres doesn't flush the cache after a write - but it DOES fsynch a table's file at each transaction commit, which in effect ends up being about the same thing. Plans are to implement a full-blown write-ahead log later this year, which will remove the necessity of fsynch'ing data files at commit time. Only the write-ahead log need by fsynch'd. The current fsynch'ing behavior is necessary to ensure that data is flushed to the disk before the separate transaction log is written marking the transaction complete. Again, a full write-ahead log will speed things up by removing the need to do that.
Postgres beat out Interbase on throughput with many connections because the version of Interbase being released for Linux is the non-threaded version. This version doesn't maintain a shared cache between the separate database processes. Postgres isn't threaded, either, but uses shared memory to cache blocks between backend processes.
Though the released version of Interbase is the non-threaded one, apparently the source for the treaded version WILL be released, and I've seen a quote from one of the Interbase folks stating his hope that folks in the Linux community will port over the threaded version, too.
In that case, scalability shouldn't really be an issue for Interbase, because the threaded version does implement cache sharing between threads.
Postgres reached its maximum throughput on the artificial benchmark at 50 users on a dual P450 with (I think) 512MB RAM, according to the PC Week guy.
Also, note that Postgres v7.0, now in beta, implements some of the missing SQL features mentioned in the article. In particular, referential integrity complete with "on cascade/update delete/set null/default" referential actions is included.
Regarding mySQL, yes, it is very fast for simple queries. For high-volume use it is less than ideal, though, as it implements concurrency control by locking entire tables. Postgres, Interbase and Oracle all implement concurrency control such that readers NEVER wait for writers, and writers only lock affected rows during a transaction (unless the user does a "select for update" or otherwise imposes a more stringent lock ).
Table locking is evil for high-volume sites. This is one reason for Oracle's popularity at high-end e-commerce sites.
Digital City and AOL run AOLserver (duh) and are written using ADP pages and TCL, though last time I looked they were using Sybase, not Oracle.
AOLserver works with a variety of database servers, not just Oracle. Large e-commerce sites don't begrudge Oracle their money. The rest of us can use the ACS with Postgres.
Since several folks have mentioned AOLserver and the Open Source website building toolkit from ArsDigita, I thought folks might be interested in learning that it is being ported to Postgres by myself and a handful of other folks.
As distributed by ArsDigita, the toolkit requires Oracle, certainly the best choice for serious, high-volume sites that require the utmost in reliability and robustness.
However, many of us don't need to scale to the size of eBay or Amazon and aren't interested in paying Oracle's licensing fees for web use (thousands of dollars a year even on Linux x86 systems), so there's been a lot of interest in an Open Source alternative.
We released a preliminary, beta subset of the toolkit running on Postgres last week. The curious may pick up a copy at http://acspg.benadida.com. AOLserver can be found at http://www.aolserver.com and Postgres 6.5 at http://www.postgresql.org.
If folks don't understand why atomicity and transactions are important for financial applications, including e-commerce web sites, they should probably hire someone who does before implementing such sites.
I use PostgreSQL for my personal web work, but think there's a lot to be said for using a tried-and-proven commercial database server when other folks' money is involved, as is the case with e-commerce. As is mentioned in this thread, Sybase has a no-cost version, yesterday's edition so to speak, available for Linux and it's good.
Speciation has been observed in the natural world. I guess you'll have plenty of time to prove that the Big Bang theory's a fallacy.
You'll have to define the difference between "significantly different species" and those that aren't. My guess is you'll simply say "any speciation that's been observed results in insignificantly different species, because the Bible makes it clear that (so-called) 'macro evolution' is impossible". In other words, circular dependence upon the Bible.
So-called scientific creationists use the same circularity in defining so-called micro and so-called macro evolution. Since "macro evolution" is held to be impossible, any evolution which is observed is dismissed as "micro evolution".
Man was not once Ape. Modern apes and man share a common ancestor.
Nitpicking aside, evolutionary theory doesn't predict that all life forms will converge into a single species, man or otherwise. The notion that human beings are the pinnacle of evolution in this sense does not exist in biology. We're certainly the most intelligent product of evolution, but not necessarily the most successful in evolutionary terms. Among other things our species, being young (very young if you believe creationists!) has not stood the test of time.
Hmmm...if you're from the US, then they're not in the least bit related to what we commonly call buzzards (turkey vultures), which are classified with the storks. On the other hand, if you're from the UK you're in the right order, anyway, as they use "buzzard" in reference to buteos.
While bald eagles do eat carrion, they also hunt and fish. In the winter, they often eat dead or dying waterfowl in cold parts of the country. I can think of one computer-using species that also eats refrigerated meat, so I'm reluctant to criticize baldies for this behavior...
1. Philip does mention that Apache/mod_perl solves the fork performance problem traditionally associated with CGI/Perl. He mentions it mostly in passing, you may've missed it.
2. AOLserver has a C API, so you can go that route rather than Tcl if you wish (though of course this gives you all sorts of good ways to crash the server). Using CGI, you can use Perl if you wish.
On the other hand, I can't imagine why I'd want to have the option of using several languages, at least when implementing the same site! I have enough trouble remembering to say "=" in SQL and "==" in Tcl without tossing in a Babelesque suite of languages. The Tcl API gets the job done, and though it's a bit kinky one can write readable code in the language.
3. A community of users of AOLserver can be found hanging out at the web/db forum of Philip's photo.net site. They'll answer your questions if you don't have friends at MIT to help you out.
4. Your argument against being constrained by AOLserver's use of Tcl seems partially based on a dislike of AOL. That's fine, but it's not really much to base an objective technical evaluation on. If it makes you feel better, AOL didn't write the server, they bought the company that did.
5. The two sites you mention aren't the only two large sites running AOLserver. Where did you get that idea?
6. If the multiprocess vs. multithreaded model doesn't really matter, why, as you point out, is Apache adopting the latter?
In the main, your argument is one of religion, i.e. open source and free software vs. free but not open source software. Given that AOLserver 3.0 is being released Open Source and GPL'd, the religous argument disappears. You're now free to make your choice based on an objective evaluation of Apache and AOLserver.
Apache/PHP seems pretty reasonable but AFAIK, at this point AOLserver still has a lot more capability built into the server proper. You can find code to pool persistent db connections for PHP scripts, for instance, but why would I want to go off on an easter-egg hunt when this functionality's already built into AOLserver, and proven to be very reliable as well?
Slashdot Mirror
"This is incorrect. Readers must wait when a page (the usual locking granularity AFAIK) is write locked or they could use data that is later rolled back. That would be an unrepeatable read and is bad."
Sorry, I am absolutely correct. Readers don't see the uncommitted data being written by another transaction, but rather previously committed data, and therefore aren't blocked by writers. It's all done on a row-level locking basis. Postgres and Interbase implement a very similar tuple-storing scheme which makes this (relatively) easy. This scheme is expensive in space, though - in Postgres, at least, you have to manually garbage collect your database with "vacuum" to reclaim space occupied by obsolete tuples. I run it automatically once a night.
Rollback doesn't affect committed data - read the definition of "commit" in any text on transaction processing if you don't understand.
I might be slightly wrong about Oracle, it may block readers of rows being written, anyone know for sure? I know this isn't true for Postgres, though - I've read the source. Writers don't block readers.
You are right that many commercial dbs do lock on a page basis. You are wrong in insisting that all do, and that row-level locking can not implement transaction semantics.
Those of us who support Open Source should be pleased that we have TWO Open Source databases that support write-locking on a row-level rather than block level basis, and that both never block readers when writing.
Postgres was slow for single users on one large benchmark run by PC Week. It's not been investigated thus far. I have some personal theories, though.
Postgres doesn't flush the cache after a write - but it DOES fsynch a table's file at each transaction commit, which in effect ends up being about the same thing. Plans are to implement a full-blown write-ahead log later this year, which will remove the necessity of fsynch'ing data files at commit time. Only the write-ahead log need by fsynch'd. The current fsynch'ing behavior is necessary to ensure that data is flushed to the disk before the separate transaction log is written marking the transaction complete. Again, a full write-ahead log will speed things up by removing the need to do that.
Postgres beat out Interbase on throughput with many connections because the version of Interbase being released for Linux is the non-threaded version. This version doesn't maintain a shared cache between the separate database processes. Postgres isn't threaded, either, but uses shared memory to cache blocks between backend processes.
Though the released version of Interbase is the non-threaded one, apparently the source for the treaded version WILL be released, and I've seen a quote from one of the Interbase folks stating his hope that folks in the Linux community will port over the threaded version, too.
In that case, scalability shouldn't really be an issue for Interbase, because the threaded version does implement cache sharing between threads.
Postgres reached its maximum throughput on the artificial benchmark at 50 users on a dual P450 with (I think) 512MB RAM, according to the PC Week guy.
Also, note that Postgres v7.0, now in beta, implements some of the missing SQL features mentioned in the article. In particular, referential integrity complete with "on cascade/update delete/set null/default" referential actions is included.
Regarding mySQL, yes, it is very fast for simple queries. For high-volume use it is less than ideal, though, as it implements concurrency control by locking entire tables. Postgres, Interbase and Oracle all implement concurrency control such that readers NEVER wait for writers, and writers only lock affected rows during a transaction (unless the user does a "select for update" or otherwise imposes a more stringent lock ).
Table locking is evil for high-volume sites. This is one reason for Oracle's popularity at high-end e-commerce sites.
AOLserver works with a variety of database servers, not just Oracle. Large e-commerce sites don't begrudge Oracle their money. The rest of us can use the ACS with Postgres.
Don't knock what you don't know...
AOLserver went Open Source months ago. http://www.aolserver.com.
Since several folks have mentioned AOLserver and the Open Source website building toolkit from ArsDigita, I thought folks might be interested in learning that it is being ported to Postgres by myself and a handful of other folks.
As distributed by ArsDigita, the toolkit requires Oracle, certainly the best choice for serious, high-volume sites that require the utmost in reliability and robustness.
However, many of us don't need to scale to the size of eBay or Amazon and aren't interested in paying Oracle's licensing fees for web use (thousands of dollars a year even on Linux x86 systems), so there's been a lot of interest in an Open Source alternative.
We released a preliminary, beta subset of the toolkit running on Postgres last week. The curious may pick up a copy at http://acspg.benadida.com. AOLserver can be found at http://www.aolserver.com and Postgres 6.5 at http://www.postgresql.org.
If folks don't understand why atomicity and transactions are important for financial applications, including e-commerce web sites, they should probably hire someone who does before implementing such sites.
I use PostgreSQL for my personal web work, but think there's a lot to be said for using a tried-and-proven commercial database server when other folks' money is involved, as is the case with e-commerce. As is mentioned in this thread, Sybase has a no-cost version, yesterday's edition so to speak, available for Linux and it's good.
Speciation has been observed in the natural world. I guess you'll have plenty of time to prove that the Big Bang theory's a fallacy.
You'll have to define the difference between "significantly different species" and those that aren't. My guess is you'll simply say "any speciation that's been observed results in insignificantly different species, because the Bible makes it clear that (so-called) 'macro evolution' is impossible". In other words, circular dependence upon the Bible.
So-called scientific creationists use the same circularity in defining so-called micro and so-called macro evolution. Since "macro evolution" is held to be impossible, any evolution which is observed is dismissed as "micro evolution".
Man was not once Ape. Modern apes and man share a common ancestor.
Nitpicking aside, evolutionary theory doesn't predict that all life forms will converge into a single species, man or otherwise. The notion that human beings are the pinnacle of evolution in this sense does not exist in biology. We're certainly the most intelligent product of evolution, but not necessarily the most successful in evolutionary terms. Among other things our species, being young (very young if you believe creationists!) has not stood the test of time.
Hmmm...if you're from the US, then they're not in the least bit related to what we commonly call buzzards (turkey vultures), which are classified with the storks. On the other hand, if you're from the UK you're in the right order, anyway, as they use "buzzard" in reference to buteos.
While bald eagles do eat carrion, they also hunt and fish. In the winter, they often eat dead or dying waterfowl in cold parts of the country. I can think of one computer-using species that also eats refrigerated meat, so I'm reluctant to criticize baldies for this behavior...
Let's see, Mr. Coward...
1. Philip does mention that Apache/mod_perl solves the fork performance problem traditionally associated with CGI/Perl. He mentions it mostly in passing, you may've missed it.
2. AOLserver has a C API, so you can go that route rather than Tcl if you wish (though of course this gives you all sorts of good ways to crash the server). Using CGI, you can use Perl if you wish.
On the other hand, I can't imagine why I'd want to have the option of using several languages, at least when implementing the same site! I have enough trouble remembering to say "=" in SQL and "==" in Tcl without tossing in a Babelesque suite of languages. The Tcl API gets the job done, and though it's a bit kinky one can write readable code in the language.
3. A community of users of AOLserver can be found hanging out at the web/db forum of Philip's photo.net site. They'll answer your questions if you don't have friends at MIT to help you out.
4. Your argument against being constrained by AOLserver's use of Tcl seems partially based on a dislike of AOL. That's fine, but it's not really much to base an objective technical evaluation on. If it makes you feel better, AOL didn't write the server, they bought the company that did.
5. The two sites you mention aren't the only two large sites running AOLserver. Where did you get that idea?
6. If the multiprocess vs. multithreaded model doesn't really matter, why, as you point out, is Apache adopting the latter?
In the main, your argument is one of religion, i.e. open source and free software vs. free but not open source software. Given that AOLserver 3.0 is being released Open Source and GPL'd, the religous argument disappears. You're now free to make your choice based on an objective evaluation of Apache and AOLserver.
Apache/PHP seems pretty reasonable but AFAIK, at this point AOLserver still has a lot more capability built into the server proper. You can find code to pool persistent db connections for PHP scripts, for instance, but why would I want to go off on an easter-egg hunt when this functionality's already built into AOLserver, and proven to be very reliable as well?