Chris, On Tue, Feb 5, 2013 at 5:58 PM, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----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. >
Understood. > I'm not suggesting that you ditch JPA or J2EE in general... it's just > that managed beans are dirt slow. I can understand why this is true; the JVM is working with a lot more code to meet your business requirements. > 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. I was about to say that I write all my own SQL, but understood. Everytime I use JPA to do CRUD, JPA is generating the SQL for me. I thought I could refer to the java app that I wrote to transfer data from legacy MS-DOS dBase IV app/database (i developed in 1994/1995) to Apache Derby (or Java DB), where the SELECT statements from the dBase IV database were pure JDBC calls, but the inserts and updates into the Apache Derby database were all JPA. I developed that prior to developing the JSF2/EJB/JPA/HTML5 web app that accesses the Apache Derby database (today). > > 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. agreed. > > - -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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
