Re: the truth about entity beans

Thu, 10 Oct 2002 15:12:40 -0700

Title: Message
The point is: Define slow. Absolutely(e.g.: slow < 160 km/h, for cars). Also, define "great" J2EE systems in production (large is the correct translation for grande in this context). Finally, remember that:
 
the Civic, the Beemer and the Cavallino, as all cars, will get you somewhere faster than a bicycle, unless there's traffic.
I don't think it's really that important that the Civic will take two extra minutes(compared to a Ferrari) to get me from home to my job.
The speed limit is 60 km per hour, so a small motorbike will get me there as well and without breaking the law.
Most of us can't afford a Testarossa ;-).
 
 
 
Ok Vinicius: Real life example I can vouch for (I leaded the team and winded up coding 75% of it).
 
CMP 1.1
Large, clustered web site. Failover, load balancing, the works.
Heavy on the DB (all pages shoot at least one "virtual" transaction, most are optimized because they're read-only).
50,000 users per hour.
500,000 page views per hour.
5,500,000 transactions per hour. (1,527 transactions per second).
All pages are served in less than 12 seconds(timeouts otherwise). 
Statistically the chance of getting an error-page due to timeouts is 1 in 100,000. This is empiric data.
Name of the site... I wish I could tell, but I can't(both my NDA and my work ethics). I coded it tough, and it is hosted in South America.
 
This is far from the ECPerf numbers, yet I haven't seen many projects that are much larger. It runs on hardware you could get for under 20 grand. It sounds like pretty fast to me... so regarding your question, basically, I could say that I have yet to find a single transactional system that cannot be implemented with EBs with performance remaining on the same order of magnitude.
 
You may check some hard numbers at:
 
 
It lists combos of hardware/app-server configurations running 4 standard applications that emulate common solution-domain themes. It serves mainly to compare hardware/software J2EE combos to each other, so it is not the definitive source, and in fact there isn't one and it never will. Every solution is different enough to deserve its own test, it depends heavily on the hardware/software environment and the only way to test it is to implement it with and without EBs, so you can expect this question to reappear here many, many times(been around this forum for almost 3 years now, and I think every fortnight somebody asks the same question). The truth is that if you need performance, forget J2EE, COM+, and CORBA. Hardcode everything in assembler. If you need ease of coding and maintenance, the price to pay for some abstraction from all the plumbing is quite small. I'm strongly biased towards EBs(and judicious use of direct JDBC) because of these issues:
 
1) O/R mapping tools aren't based on standards. O/R tools allow for little space for optimization without compromising data integrity. O/R is a one way trip, and avoiding vendor lock-in is one of the reasons I got involved with J2EE in the first place.
2) Making my own DAO-O/R mapping is reinventing the wheel. I don't want to maintain code that isn't directly related to the solution domain. I've got stuck with this kind of work and I wouldn't wish it to my worst enemy. But this is like the blues: you gotta feel the blues to play the blues.
3) Pure, direct JDBC usually leads to code JDBC access on a use-case by use-case basis or to implement code ownership(if some reuse is achieved). I like coding things Once And Only Once and code ownership wastes a lot of time. My time. And lost time cannot be regained, no matter what Proust may have to say about it ;-)
4) I'm lazy. I rather make the customer spend a few more bucks on the server hardware/software than on paying me(and my rates are stiff enough for it to be cheaper, too), and spend that time with my girlfriend(o mais grande do mundo ;-) ).
 
 
My 2c,
 
Juan Pablo Lorandi
Chief Software Architect
Code Foundry Ltd.

Barberstown, Straffan, Co. Kildare, Ireland.
Tel: +353-1-6012050  Fax: +353-1-6012051
Mobile: +353-86-2157900
www.codefoundry.com
 
Disclaimer:
 
Opinions expressed are entirely personal and bear no relevance to opinions held by my employer.
Code Foundry Ltd.'s opinion is that I should get back to work.
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]] On Behalf Of Vin�cius de Faria Silva
Sent: Thursday, October 10, 2002 10:41 PM
To: [EMAIL PROTECTED]
Subject: Re: the truth about entity beans

I am sure that it is not slow! Aren't you?
 
Vin�cius
----- Original Message -----
Sent: Thursday, October 10, 2002 6:27 PM
Subject: RE: the truth about entity beans

Hi Vinicius,

 

            Is BMW a slow car? A lot of people say that it's a pretty fast car others that it's not.

            Any thoughts?

 

Regards,

 

            Dimitar

 

-----Original Message-----
From: Vin�cius de Faria Silva [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 09, 2002 12:13 PM
To:                  
Subject: the truth about entity beans

 

I've been following discussions about the pos and cons of entity beans for 2 years.

I'm not sure yet if this approach is good or not, mainly in terms of performance.

I hear a lot of system architects say that entity beans are slow.

What's the true about this issue?

Entity Beans are slow?

If not, which great J2EE systems(in production) are based on entity beans?

Are there benchmarks which proof that entity beans can provide good performance?

 

regards,

 

Vin�cius

Reply via email to