File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB and other Java EE Technologies and the fly likes Don't need no distributed app, but DO need performance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Don Watch "Don New topic

Don't need no distributed app, but DO need performance

Paul Oprea

Joined: Oct 24, 2002
Posts: 4
I need to build a classic n-tier Internet application; its particular aspects are:
- need to support 3 databases (Oracle, SQL Server, IBM DB2);
- some decent performance;
- rich business babling aka application logic ;
- NO NEED to be distributed for the application layer;
all I need is a fat, LAN-stuck application server that talks to dumb, fast and granular stored procedures on the DBs. However, to keep database code writing as simple as possible, all the transactions need be directed from the app layer; a pooling mechanism would also be heavily welcomed.
With these requirements, do I have to adopt necessarily J2EE/EJB or what else could I use - among Java technologies, of course?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17421

Would that clean, reliable user-/operator-/2am programmer-got-paged -friendly systems carried as many "geek points" as "efficient" ones do.
First off, you seem to assume that most J2EE systems carry a lot of client-side code. Not so! is a high-performance J2EE (WebLogic-based) system. Been shopping there? Pick apart their web pages. You won't see much in the way of heavy client code. Among other reasons, 2 stand out:
1. The Neanderthal-era JVMs that most users have installed can't do that much by themselves.
2. Two of the biggest proponents of Java are Oracle and Sun. Did you really THINK Ellison and McNeilly would want to see systems that needed a smart client (i.e. Microsoft Windows)?
Face it. Until Moore's Law bottoms out, coding efficiency for efficiency's sake isn't worth it. By the time the system hits production, all the hardware will have doubled in speed. It's MUCH less important to "be efficient" as to simply avoid doing grossly inefficient things. Some of these are obvious, like not using a bubble sort to sort 500,000 random items. Some are less so, like not using a heap sort to sort 500,000 NON-random items. A lot of times, it's just getting a good feel for what's resource-expensive and what's not, and when it matters.
When it matters is important. If you process an HTML request in 40ms instead of 100ms, it may be a meaningless efficiency unless you can use the other 60ms elsewhere (I call this the "You can't save nanoseconds in a jar" effect). On the other hand, if you have database operations jamming up right and left and people are seeing 20-second response times, you're in big trouble. They're not going to be impressd by your 40ms HTTP processing. So Rule 1 of Optimization is "Optimize where it counts".
Rule 2 is less known, but even more important: "Until you've MEASURED performance, you only THINK you know where the problem is. You'll almost always think wrong." I can attest to this from personal experience!
Anyway, enough off the editorial page. Check out the J2EE design patterns at - they have some proven techniques for creating clean, reliable, and efficient J2EE-based systems. J2EE isn't the only way to go, but it has the advantage of being well-known, widely-supported, and mostly debugged, so unless you have unusual needs, or intend to make a career out of a creating and supporting a custom system, you should consider it first.
Also, as far as EJBs go, you can hear all sorts of opinions, but EJBs aren't designed first and foremost for performance - unless your idea of performance includes time not spent recovering from bad transaction management. I use EJBs quite a bit, but one reason why I do so is that I have a useful little generator for EJBs and support code, so it saves me time (I like to use ME efficiently!). Another reason is that since EJBs are modular, I can always yank one out and plug in something faster if I actually detect a performance problem there. It would be harder to tune if the system was more amorphous.

An IDE is no substitute for an Intelligent Developer.
Rob Misek
Ranch Hand

Joined: Sep 24, 2002
Posts: 41
Hi Paul,
If you are building from the ground up and are concerned about performance (which is a great start since that most seem to think of this last ) I would point you to Tangosol's Coherence in-memory clustered cache/objectstore.
Coherence can be used to keep your live data in the application tier as much as possible to avoid repeated calls to the DB.
Have a look.

<a href="" target="_blank" rel="nofollow"></a><br /><a href="" target="_blank" rel="nofollow">Coherence:</a> Easily share live data across a cluster!
Paul Oprea

Joined: Oct 24, 2002
Posts: 4
Thanks a lot for the "editorial"
No, I wasn't talking about lots of client code. In my app I will only have as client code some simple Javascript validation for not filling a field or so. And the HTML pages with this simple client validations are anyway produced by molding the XML which is internally manipulated by my app layer into a set of XSLs, so here client code and graphics is pretty well limited and kept under control ( yes, programmers DO like to mix and mess the things).
Then, YES, I'm afraid of performance killers. Not of the nanoseconds in a jar but of those who damage by orders of magnitude. I know how to design an efficient application in the Microsoft world just because I have some years of experience and a MCSD (which makes me a "Microsoft brainwashed" like they say :roll: ) but as I arrived in the Java world, I'm a newbie on technical details and still don't want to repeat the mistakes that I've seen dozens of times the other side and I see that J2EE makes them possible as well (seems you can shoot yourself in the foot in any language or technology if you really want to ). So your rule number 1 is what I want but don't know how for the moment.
Rule number 2... here you confused me how is it possible that after you're carefully designed a system in which you avoided rule 1's booby traps and convinced the fellow programmers to stick to that vision, still to land in uncertainty?
P.S. and I got scared of EJB's 101 Damnations
[ October 25, 2002: Message edited by: Paul Oprea ]
I agree. Here's the link:
subject: Don't need no distributed app, but DO need performance
jQuery in Action, 3rd edition