I quote from above:
"
The criticism of EJB the author makes confirms what I have been suspecting for some time now:
EJBs are evil, and should be avoided at all costs, except in a few cases.
"
also: www.basebeans.com/bad.jsp can give you more info. You can just search EJB on google for more.
.V
Taylor, Jason wrote:
V-- What did you specifically see as a performance problem? Was it jndi
lookups, I/O, serialization/deserialization, memory allocation, failover or
what?
I also think they are often mis- or over-used-- I'm interested in the cases
you ran into. Do you care to share?
-JT
-----Original Message-----
From: V. Cekvenich [mailto:vicc@;users.sourceforge.net]
Sent: Tuesday, September 24, 2002 4:26 AM
To: [EMAIL PROTECTED]
Subject: EJB / was Struts and high performance sites
They are hype marketed as such. Most newer developers try them, as I did when I was new, but in production they did not scale, so we removed them. On new sites I skip the writing them part, since people would only remove them in production. (some management that take EJB to production are so upset that they go to the cached .NET ADO, so I steer my client's clear).
Read www.basebeans.com/bad.jsp links for other's opinion.
Some people disagree with them, but I had similar experience.
V.
Daniel Joshua wrote:
V. Cekvenich,The slow part is DAO in J2EE (and ADO in .NET). Avoid any EJB, they do not scale.I though EJBs were designed to allow scalling? Regards, Daniel -----Original Message----- From: news [mailto:news@;main.gmane.org]On Behalf Of V. Cekvenich Sent: Tuesday, September 24, 2002 5:56 PM To: [EMAIL PROTECTED] Subject: Re: Struts and high performance sites Not a high volume of users, and 7 transactions per second? Should fit on a single medium box (if not a laptop) if you do it right. You have to worry about creating objects if you write your own framework (you can put beans in session or requests, and request is better mostly), and then you have 2 projects, your app and a framework, and you won't do better than the Struts team and what about framework bugs? Also, with Struts, my clients are able to write several modules(pages) per day per developers, how's that for productivity or beating the schedule? Some of the Struts sites are 50 times more concurrent users I have worked on, no problem. The slow part is DAO in J2EE (and ADO in .NET). Avoid any EJB, they do not scale. Some good choices is RowSet(I do metadata w/ reflection to auto gen SQL updates - RowSet also avoids BO/DTO/VO mapping and GC), Resin, pgSQL, Eclipse or CodeGuide IDE, Linux/KDE and J:Rockit VM or IBM VM (Sun VM and Sun Inc. have issues). Sample good practices code on http://basicPortal.sf.net, FREE! (If you have a large app or large # users, let a mentor help. many are on this list, it is cost effective, but not because of Struts only) V. Struts Mentor 917 345 1445 [EMAIL PROTECTED] ("Mentor's helps you do it faster/cheaper) David Zimmerman wrote:Hi, we are building a webshop for a site with a high volume of users, approx.800 concurrent users and 25k transactions per hour. We are going to useJ2EEas the ground platform. I am now considering some design choices whereusingStruts is one of them. However I have some questions regarding the performance of Struts. I know this issue has been up many times before butIhave never been able to find any satisfying answers, so...What, if any, overhead does the Struts controller generate? This questionmust of course be seen in the context of writing your own controller or using any other framework. However, what is Struts overhead?What overhead does the use of form beans generate (in the sense of objectscreated, memory use, the use of reflection, speed)Custom tags (Struts' or other). Would they be applicable in a case likethis? Wouldn't there be a massive creation of objects for every request?Please help me out here! I really want your knowledge on this! Regards David Zimmerman ____________________________________________________________ Tired of all the SPAM in your inbox? Switch to LYCOS MAIL PLUS http://www.mail.lycos.com/brandPage.shtml?pageId=plus-- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>-- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
-- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>