-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Howard,
On 2/1/13 9:57 PM, Howard W. Smith, Jr. wrote: > On Fri, Feb 1, 2013 at 2:20 PM, Christopher Schultz > <ch...@christopherschultz.net> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEUEAREIAAYFAlERjrMACgkQ9CaO5/Lv0PDaVgCTBdUHBpXKHZgl074pzojY1SZu 6ACfdhTJLLtK7GkKdra3E8gc4mntdGI= =Ruvy -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
