The future of Java
in [Java Programming]
|
From: Arne Vajhøj on 25 Nov 2009 20:31 David Segall wrote: > Roedy Green <see_website(a)mindprod.com.invalid> wrote: > >> On Sat, 21 Nov 2009 18:59:04 +0000 (UTC), Martin Gregorie >> <martin(a)address-in-sig.invalid> wrote, quoted or indirectly quoted >> someone who said : >> >>> How do you rate H2 against Derby and HSQL? >> For a comparison of PosGreSQL and MySQL see >> http://mindprod.com/jgloss/postgresql.html >> >> The information is a few years old. > > And it ignores the gulf between the license conditions of the two > products. MySQL is GPL but the drivers are not LGPL so you can only > incorporate a MySQL driver into your application and distribute the > MySQL database if your software is open source. Even if you have some > weird objection to open source there is a genuinely, freely > distributable, version of all the commercial heavyweight databases > although they may restrict the number of processors, RAM or disk size. > Why risk contravening MySQL's deliberately confusing license > conditions? MySQL gives you the choice of free via a GPL license or paying for a license on commercial terms. If you want something free under Apache/BSD/similar license, then MySQL is not a good choice. But a lot of people can live with GPL and a lot of people can live with commercial terms. Arne
From: Arne Vajhøj on 25 Nov 2009 20:54 Roedy Green wrote: > On Sun, 22 Nov 2009 21:56:54 -0500, Arne Vajh�j <arne(a)vajhoej.dk> > wrote, quoted or indirectly quoted someone who said : > >> Neither have much of a choice. > > I have seen vendors wriggle out of these sorts of promise by creating > a new product and just letting the old one languish. The wording of > the GPL licence may make that difficult for Sun and Oracle. Does the > licence apply to them too? Surely a vendor has the legal right to > change the terms of a licence. Oracle own the copyright and could make MySQL 7.x closed source, but the source code for 3.x/4.x/5.x/6.x would still be open source. And with almost certainty that code would be forked if Oracle tried something like that. But Oracle would not do it, because it does not make any business sense. Oracle already have a closed source database. Arne
From: Arne Vajhøj on 25 Nov 2009 20:55 Roedy Green wrote: > On Sun, 22 Nov 2009 22:05:05 -0500, Arne Vajh�j <arne(a)vajhoej.dk> > wrote, quoted or indirectly quoted someone who said : > >> #PostGres does not crash under heavy loads. >> >> No databases are supposed to do that. > > Under heavy loads a system can have can a variety of behaviours: > > in increasing desirability > > 1. the system crashes outright. > > 2. the throughput drops precipitously. (e.g. virtual ram thrashing). > > 3. the throughput maintains a plateau, no matter what the load. That does not justify your claim on that page of it being an advantage of PostgreSQL. Arne
From: Arne Vajhøj on 25 Nov 2009 21:05 Tom Anderson wrote: > One thing that leaped out at me when reading the H2 docs is that it uses > table-level rather than row-level locking. For read-heavy tables, this > is fine, because read locks can be shared, but it means that if you have > multiple threads writing to a single table, even if they're touching > entirely different rows, they'll serialise, which will kill concurrency > and throw its body in a ditch. > > I have had serious problems with table-level locking in real systems. We > have an app which occasionally loads huge (well, moderate) amounts of > data into a database, doing so via a process with quite a bit of CPU > overhead. The machines running the app and databases have multiple > cores, and there's fast disk (actually a SAN) at the backend, so we use > multiple threads to get the most out of the hardware. We developed with > Oracle as our RDBMS, and it all went swimmingly. We ran it up on a > client's test farm with MS SQL Server as the database, and it fell flat > on its face. Turns out that unlike Oracle, MSSQL uses table-level > locking by default. The work around was to drop the number of threads > used to one, and endure amazingly long load times. A later solution was > to enable row-level locking in MSSQL, although to be honest, even then > it crawled compared to Oracle. We never (or haven't yet, more > optimistically) got to the bottom of that. > > Hmm. A bit of googling suggests that MSSQL uses row-level locking by > default, which doesn't fit this story. It's possible an overenthusiastic > DBA had changed this somehow. Or that we were running into lock > escalation - each transaction inserted many rows, so it's possible each > one started out with row locks, but then decided to escalate to a > whole-table lock. SQLServer has never used table level locking as basic locking. It inherited page level locking from Sybase. And row level locking was added in SQLServer 6.5 in 1996. > Coming back to H2, it does also support an entirely lock-free > concurrency strategy in the shape of multi-version concurrency control > (as made famous by Interbase/Firebird), but this is experimental, and > currently single-threaded, which means it's not a solution in situations > like the above. > > A bit of reading reveals that other databases which use MVCC, beside H2 > and Firebird, are Oracle (which explains why it worked where MSSQL > didn't!), PostgreSQL, MS SQL Server since 2005 (as an option, though?), > and even MySQL with the right storage engine. I've seen Sybase mentioned > as having MVCC, but googling turned up strong indications that it uses > orthodox locking. So, MVCC is used by everything except that, the > lightweight java databases, and, er, DB2! IBM DB2 + Sybase ASE + MS SQLServer in default config + Informix + SQLite + MySQL with MyISAM seems to me to be something like 1/2-2/3 of all the worlds databases. Arne
From: Lew on 25 Nov 2009 21:10
Arne Vajhøj wrote: > scalablity - largest public known MySQL customers are bigger > than largest known PostgreSQL customers As of May, 2008, supposedly the largest database installation in the world was on Postgres. <http://it.toolbox.com/blogs/oracle-guide/worlds-largest-database-runs-on-postgres-24979> -- Lew |