tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: [Seriously OT] Help in diagnosing server unresponsiveness
Date Tue, 05 Feb 2013 22:58:59 GMT
Hash: SHA256


On 2/1/13 9:57 PM, Howard W. Smith, Jr. wrote:
> On Fri, Feb 1, 2013 at 2:20 PM, Christopher Schultz 
> <> wrote:
>> If you want to improve performance even more, ditch EJB
>> altogether.
> Wow, that hurt. ditch EJB altogether? I 'grew up' on EJB. When I
> was migrating from JSF managed beans to CDI managed beans, I
> recognized that I could reference EJBs via @Inject or @EJB via 
> TomEE/OpenWebBeans, but I stuck with @EJB...'just because'.
> when I first read your recommendation, earlier on, i thought to 
> myself, okay, that should be easy, but now, I don't know how I
> would 'ditch EJB altogether'. All of my EJBs are accessing database
> via JPA; there are a few native SQL statements, lot of dynamic SQL
> statements that I redefined as named queries. If you are referring
> to CDI managed beans performing database access... I think I read
> one blog that stated that CDI can do anything that EJB can do, but
> still, I guess I have not seen any examples where CDI bean is
> accessing database.
> So, why do you recommend to 'ditch EJB altogether'... to improve 
> performance? please explain.

EJB takes normal classes and interfaces and wraps them in remotable
proxies that can be used across huge clusters of loosely-related
servers. Most apps don't need all that, or, if they do, can do it in a
smarter way because the author understands the use cases and can beat
a generalized system handily.

I'm not suggesting that you ditch JPA or J2EE in general... it's just
that managed beans are dirt slow. I haven't used Hibernate or even JPA
but older O-R mappers (Torque, etc.) all sucked and ended up pulling
way more data than necessary from the database. Years ago, we
ripped-out all that crap and wrote our own SQL ourselves. Not only
were we able to see a dramatic improvement in performance (sorry, I
don't have numbers for you... it's been a while) but we now have
full-control over transactions, timeouts, complex where clauses, etc.
with out having to fight against an API that wants to hide all that
complexity from you.

IMO, developer performance trumps runtime performance most of the
time. So, if you can create a more maintainable system in less time by
using EJB (or whatever), then you go ahead and do it: servers are
cheap, while developer time is expensive.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message