Slashdot Mirror

← Back to Stories (view on slashdot.org)

Java EE & Streaming Architectures

Posted by Hemos on from the a-better-cornerstone-for-a-better-building dept.

Amin Ahmad writes "Implementing a streaming architecture on a Java EE application server provides asymptotically better memory performance, and, hence, scalability, than current, widely-implemented, Java EE patterns endorsed by Sun. This article provides a concrete implementation of a streaming architecture and compares its scalability to two other, standard implementations: Remote EJB and Local EJB-based solutions. The implementation based on a streaming architecture comes out the hands-down winner: for example, when sending back 300 rows of data to the client, the Local EJB solution fails beyond 16 concurrent users whereas the streaming solution is still running at 128 concurrent users! The article includes complete source code and the entire results database for the stress test. I would be interested in hearing your feedback."

3 of 40 comments (clear)

  1. A good reminder if anything. by FooMasterZero · · Score: 2, Insightful
    This article is pretty bare when it comes to the title of the article. Out of all the content in the article there are few paragraphs that really talk this streaming architecture. I would almost go to say this isn't streaming cause this is just common sense. However it is just a name and that is my two cents. But I have included the article that pretty drives the author's point as the rest of the article is merely setup and post-analysis.

    So the moral of this article, if you read and process any decent amount of data, process this data in a serialized fashion; for example use SAX instead of DOM. Also make sure your JDBC connections are tuned correctly to exhibit this 'chunking' behavior or else it won't matter anyways.

    From the Article:

    Lines 8 through 14 open a connection to the database and configure the statement. It is critical to configure the connection and statement so that the database server does not send the entire result set to the application server, but rather sends chunks on demand. Clearly if the entire dataset is sent in a single piece to the application server, we will have nothing to show for our labors! To accomplish this in MySql 5 requires setting useCursorFetch=true and setting the fetch direction of the statement to ResultSet.FETCH_FORWARD. DB2 automatically chunks the data if the statement is scrollable (either ResultSet.TYPE_SCROLL_INSENSITIVE or ResultSet.TYPE_SCROLL_SENSITIVE). Finally, note that normally a connection would be obtained from an application server's connection pool, but for the sake of producing an application that can be deployed easily, this example takes a shortcut. Lines 17-25 loop through the result set, populating a president object and writing it to the page in each pass. This is the crux of the streaming architecture: No more than a single row is kept in memory at once.
  2. Re:Surprise, surprise... by sonofagunn · · Score: 2, Insightful

    I think you're missing the point of the article. Whether he is using EJBs or just an EJB-like pattern, the analysis of the algorithms' scalability is the same. It's common sense, but a lot of people who are trained in EJB development always do things the same way without really thinking about what's actually happening behind the scenes. This article makes a good case for using a database cursor and "streaming" objects to the web page as you read them, as opposed to letting a bean read the entire result set and then creating the web page. It absolutely will scale better for large result sets and large numbers of users.

  3. Re:Java is great for learning by LizardKing · · Score: 3, Insightful

    Wow, so much ignorance in just one post.

    JSP is a nice try to eat into the PHP market.

    Nope, different markets. JSP is for people who understand the Model, View, Controller architecture and are capable of building systems around generalised code (POJO's). PHP is ideal for small scale web apps, but that's it - it encourages unstructured code and no separation between presentation and business logic tiers.

    But it's so slow and far away from the reality of productive systems that the Apache crew rather forked their server to a Java-only server (Tomcat) to keep their httpd codebase clean and free of anything that is Java.

    Tomcat originated with Sun, as a proof of concept web container. The code was donated to the Apache foundation, and there has never been any plan to merge it with the Apache HTTP daemon. People usually proxy from Apache to Tomcat, as they have static content to serve as well, or just to keep web servers in the DMZ behind a single firewall and the web container servers behind a second firewall so that database connections and things like CORBA connections are more secure.

    EVen if Java is open source now. There is a reason why Java applets have become almost distinct. Even Flash evidently performs better than an Java applet.

    I assume you mean "extinct" rather than "distinct". However, applets have bugger all to do with JSP and webapps. They were a neat way of promoting the Java platform when it came out, but are tiny part of what made Java popular.

    And why the hell would anyone still need this "Compile once, run anywhere." nonsense?

    Because it's easier to port a virtual machine than a complete toolchain.