The future of Java
in [Java Programming]
|
From: Lew on 24 Nov 2009 09:06 Roedy Green wrote: >> Years ago I read that computer companies often do well in recessions. >> Companies try to save money by firing people and replacing them with >> computers. Mark wrote: > Or they cancel new IT projects to save money and cut back on > maintenance. Penny wise, pound foolish. -- Lew
From: Tom Anderson on 24 Nov 2009 13:35 On Mon, 23 Nov 2009, Qu0ll wrote: > "Tom Anderson" <twic(a)urchin.earth.li> wrote in message > news:alpine.DEB.1.10.0911221253400.7260(a)urchin.earth.li... >> On Sun, 22 Nov 2009, Qu0ll wrote: >> >>> "Arved Sandstrom" <dcest61(a)hotmail.com> wrote in message >>> news:9CXNm.54457$PH1.35011(a)edtnps82... >>>> Lew wrote: >>>>> Roedy Green wrote: >>>>>>> Even if they are swallowed in the blender, I would like to publicly >>>>>>> thank them their part in providing me Java, MySQL and Open Office. >>>>> >>>>> Arne Vajh?j wrote: >>>>>> SUN did not provide you MySQL. SUN just acquired the company >>>>>> not long ago. And have lost most of the original people since then. >>>>> >>>>> Small loss. >>>>> >>>>> I rate MySQL far, far below Postgres, Derby and the free versions of >>>>> Oracle DB and IBM DB2. >>>>> >>>> That's roughly my take on it as well. Choosing from PostgreSQL, SQL >>>> Server or Oracle XE for my local work on Windows/Linux/Mac OS X lets me >>>> do everything I need to do to support my company's clients. In fact I use >>>> SQL Server on the odd .NET project only to keep acquainted; otherwise I'd >>>> pare my choices down to Postgres and Oracle XE. Nothing against Derby - I >>>> just haven't had occasion to use it now for some years. >>> >>> The beauty of using Derby of course is that it just installs as part of >>> your application. No separate or specialised installers required. >> >> This is also true of H2 and HSQL, no? You just add their JARs to your >> application, and it gains the ability to make and use their databases >> wherever it goes. Of course, with Derby you don't even need to add a JAR, >> but that's such a trivial thing to do that it hardly seems like a >> significant advantage. > > True, but I was comparing Derby to Postgres and Oracle XE as Arved had > indicated his choice was narrowed down to those two. Aha, my mistake. tom -- 1 p4WN 3v3Ry+h1n G!!!
From: Tom Anderson on 24 Nov 2009 14:06 On Sun, 22 Nov 2009, Martin Gregorie wrote: > On Sun, 22 Nov 2009 15:10:32 -0800, Roedy Green 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. >> >> I understand that Derby is fast, but ram resident only. It is for small >> databases only. > > I'm interested finding out if Derby, H2 or HSQL could be used as a > lighter weight, portable alternative to PostgreSQL, i.e. minimal changes > to SQL queries and schema, full ACID capability, capable of dealing with > fairly large tables on disk. 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. As an aside, part of the moral here is to develop or at least integration-test on the same infrastructure as you'll be deploying to. My defence here is that we originally developed the app for client A, who used Oracle, and only got involved with client B's MSSQL setup, where the above story happened, later. 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! A final caveat on that postscript to a caveat: MVCC is not a cure-all, because it introduces certain kinds of overhead that lock-based systems don't have. For instance, i have read that SELECT COUNT(*) FROM SOME_TABLE is O(n) in an MVCC system, because it has to look at version numbers on the rows, whereas a locking system can do it in O(1) by looking at the metadata. tom -- 1 p4WN 3v3Ry+h1n G!!!
From: Martin Gregorie on 24 Nov 2009 17:00 On Tue, 24 Nov 2009 19:06:21 +0000, 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. > That's good to know. However, for my immediate application, table locking is probably not a problem since during normal processing DB updating is a single threaded bulk load that can be done overnight and/or in a quiet time. The only other accesses are read-only apart from occasional bouts of data cleansing. > I have had serious problems with table-level locking in real systems. > I've been bitten by that in the past too. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Roedy Green on 24 Nov 2009 20:23
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. -- Roedy Green Canadian Mind Products http://mindprod.com I mean the word proof not in the sense of the lawyers, who set two half proofs equal to a whole one, but in the sense of a mathematician, where half proof = 0, and it is demanded for proof that every doubt becomes impossible. ~ Carl Friedrich Gauss |