48 messages in com.mysql.lists.javaRe: SubQueries and Temp Tables
FromSent OnAttachments
Arul25 Jun 2002 21:04 
Arul26 Jun 2002 02:30 
Ralf Narozny26 Jun 2002 02:30 
Dave Morse26 Jun 2002 07:16 
Alexander Barkov26 Jun 2002 08:15 
Paul DuBois26 Jun 2002 17:36 
Dave Morse27 Jun 2002 07:12 
Paul DuBois27 Jun 2002 08:03 
Peter T. Abplanalp27 Jun 2002 08:06 
Dave Morse27 Jun 2002 08:16 
Andrew Houghton27 Jun 2002 09:09 
Frank Gates27 Jun 2002 09:28 
Timothy Bennett27 Jun 2002 10:16 
Dave Morse27 Jun 2002 10:39 
Frank Gates27 Jun 2002 10:48 
Dave Morse27 Jun 2002 10:50 
Dave Morse27 Jun 2002 10:55 
Pål Arne Hoff27 Jun 2002 12:04 
Arthur Fuller27 Jun 2002 14:34 
Mark Matthews28 Jun 2002 06:27 
Mark Matthews28 Jun 2002 06:37 
Dave Morse28 Jun 2002 11:38 
Frank Gates28 Jun 2002 12:16 
Arthur Fuller28 Jun 2002 12:21 
Arthur Fuller28 Jun 2002 12:28 
mike markovich28 Jun 2002 12:49 
Jeff Kilbride28 Jun 2002 13:04 
Dave Morse28 Jun 2002 14:01 
Scott Hodson28 Jun 2002 14:12 
Jon Frisby28 Jun 2002 14:46 
Dawn Wolthuis28 Jun 2002 16:06 
Tim Endres28 Jun 2002 16:45 
Mark Matthews30 Jun 2002 17:30 
Mark Matthews30 Jun 2002 18:50 
Tim Endres30 Jun 2002 19:05 
Scott Hodson30 Jun 2002 20:35 
Jeff Kilbride30 Jun 2002 21:19 
Mark Matthews01 Jul 2002 06:13 
Dave Morse01 Jul 2002 08:32 
Dave Morse01 Jul 2002 18:46 
Jeff Kilbride01 Jul 2002 18:49 
Mark Matthews01 Jul 2002 19:23 
Scott Hodson01 Jul 2002 21:01 
Admin01 Jul 2002 23:21 
Jon Frisby02 Jul 2002 11:59 
Admin03 Jul 2002 11:52 
Dave Morse03 Jul 2002 12:01 
Arthur Fuller03 Jul 2002 12:23 
Subject:Re: SubQueries and Temp Tables
From:Jeff Kilbride (je@kilbride.com)
Date:06/30/2002 09:19:49 PM
List:com.mysql.lists.java

Yes, but I think what Mark is saying is that you can't *accept* 1000's of connections with a java-based database in a single JVM on a single box. Java I/O just doesn't scale like that.

--jeff

You could generate 1000s of connections using multiple VMs on multiple machines.

-----Original Message----- From: Mark Matthews [mailto:mmat@thematthews.org] Sent: Sunday, June 30, 2002 5:31 PM To: Frank Gates; Dave Morse Cc: 'Arthur Fuller'; 'Paul DuBois'; ja@lists.mysql.com Subject: Re: SubQueries and Temp Tables

Dave Morse writes:

You are kidding right? There are several 100% Java databases that run circles around MySQL in performance. No big deal there. It isn't the language as much as the design and implementation that determines performance when it comes to an application as complex as

an RDBMS.

Under load with 1000's of connections? Sorry, you lose. You run out of JVM before you run out of horsepower of the entire system because of Java's non-scalable I/O model.

Until these apps are re-written with NIO, and NIO is stable, it isn't possible.

(From the next response to this thread by Dave):

JDataStore, FirstSQL/J, HypersonicSQL.... Haven't seen tests on PointBase or Cloudscape.

The FirstSQL benchmark (http://www.firstsql.com/bench12.shtml) is pure hooey. The benchmark does not test the system under load, and the FirstSQL team doesn't appear to know how to install MySQL correctly, and bow-out (see their disclaimer). Also, did they ask either Pointbase or MySQL-AB to install and tune the application to get the best results possible for their application? My guess is, no. If you're basing your opinion on these results, you're either biased or naiive, or both.

If you want to see as realistic a benchmark as possible for Java, by a third party, with participation from the database vendors, see the E-Week database shootout at http://www.eweek.com/article2/0,3959,293,00.asp

-Mark

--------------------------------------------------------------------- Please check "http://www.mysql.com/Manual_chapter/manual_toc.html" before posting. To request this thread, e-mail java@lists.mysql.com

To unsubscribe, send a message to the address shown in the List-Unsubscribe header of this message. If you cannot see it, e-mail java@lists.mysql.com instead.

To unsubscribe, send a message to the address shown in the List-Unsubscribe header of this message. If you cannot see it, e-mail java@lists.mysql.com instead.