The 'Bitter Cost' of Enterprise JavaBeans

Discussions

News: The 'Bitter Cost' of Enterprise JavaBeans

  1. The 'Bitter Cost' of Enterprise JavaBeans (28 messages)

    Before using EJB, you should carefully weigh the pros and cons. There are plenty of both. To do this, you should carefully weigh your application requirements, and make sure that the benefits that you’ll see from EJB will offset the additional complexity that you’re bound to encounter. A new public review chapter from the book-in-progress "Bitter EJB" looks at the costs of using EJB.

    Download and Review 'The Bitter Cost' chapter from the Book-In-Review: 'Bitter EJB'

    Threaded Messages (28)

  2. For JBoss developers[ Go to top ]

    As far as I understand, JBoss' architecture allows some of the unnecessary container services to be turned off. Has anyone ever tried to turn off some of the interceptors on the entity bean ? And if yes,

    1. Which interceptor did you turn off ?
    2. Any performance improvements ?
  3. Bitter Altenratives[ Go to top ]

    From the Altenraties chapter in book:
    "When dealing with complex query processing on relational data sets, SQL can be an indispensable component of an architecture. However, using SQL for simple queries can be problematic. In general, Java application developers are more comfortable thinking in object terms than in relational terms, and will sometimes create quite inefficient queries or queries that do not do exactly what the developer intended."

    ??

    If you access the db, someone on the team knows SQL. THere is no way "automatic" sql is better than manual sql.
    Anything that uses XML querry, or EQL or OQL, is somehting you have to learn on top of SQL.

    And like he said first, if you have a complex (or large) system, you do not have a choice but to go SQL w/JDBC.
    See RowSet thread in "Servlets & EJB" thread.
    .V
  4. Bitter Altenratives[ Go to top ]

    I think his point is that while there usually is someone on the team whos handy at SQL, usually most are not. Having taught at a major consulting shop, many developers don't understand basic SQL relational concepts, let alone outer joins, subselects, etc.

    And while manual, fine-tuned SQL can beat automated SQL, its most likely the SQL used won't beat it, nor do most business apps need the extra milliseconds of speed. And I know I would pick a maintainable, vendor agnostic system over one that requires a standby DBA (and having been one for a short time, I think most DBAs would rather not be bothered either).

    And while Entity Beans cannot scale that large, many OR and RAD frameworks support large result sets in a much more sophisticated manner without every developer on the team memorizing java.sql.*.
  5. Bitter Altenratives[ Go to top ]

    Steve,
    Of course I disagre,

    The O/R's can't handle very large load or complex apps, and as you know SQL can save performance exponentialy, that is minutes to milieseconds. Let me repeat: Somone that knows sql can take a querry that takes minutes to miliseconds. (By simlifying joins for example)
    (I agree that any perofrmance of less than 1/3 of a second people do not notice).
    If you do DB, somone must know java.sql and SQL.

    Anyways, I do project recovery, etc. for sites that said, "I do not need to know SQL".

    .V
  6. Bitter Altenratives[ Go to top ]

    "The O/R's can't handle very large load or complex apps"

    This is a pretty broad statement, which O/R tools have you tried? Have you tried JDO?

    I can live with a performance hit if it:

    1) Increases developer productivity
    2) Reduces bugs
    3) Eases maintenance (less code to maintain)
    4) Gives developers more time to solve business problems

    For me JDO does all of the above.

    Michael
  7. Bitter Altenratives[ Go to top ]

    The O/R's can't handle very large load or complex apps,


    That is simply not true. If you use a good O/R mapper and you know what you are doing, the overhead is minimal, say less then 5-10%. You can also implement your own O/R mapping layer that is not generic, but highly specific to your application (writting non-generic O/R mapping layer is much less hard then writting generic one). This way you loose some of the developer productivity, but you can gain in performance and do not have to pay for commercial O/R mapper.

    >> Let me repeat: Somone that knows sql can take a querry that takes minutes to miliseconds. (By simlifying joins for example)

    And let me say: Someone that knows O/R mapping can save hours of developmant, testing and maintaining time and maintain the same (or even better, see below) level of performance as fine tuned SQL.

    One benefit of the O/R mapping is very often forgotten when we are talking about performance. That is caching. Implementing caching when you take O/R mapping approach is hundreds of times easier then without it, for example using record set apporach (and I implemented caching using both). And caching can give you order(s) of magintude better performance then the finest tuned SQL that have to go to the database again and again.

    Sure, there will always be people that produce bad code and bad performant applications (and a lot of job for you), and I admit that less experienced people can make mistakes easier with O/R approach, than with, for example, record set approach.

    Regards,
    Mileta
  8. SQL for Dummies[ Go to top ]

    Without getting into the OR debate I'd just like to address the comment that "not many developers understand the fundamentals of SQL" as being a valid argument for going with mapping tools etc.

    Personally speaking SQL is relatively simple, and the idea of anyone working on the persistence layer of an application who does not understand SQL or fundamental relational concepts is literally unthinkable.

    EJB and persistence frameworks are great and take a lot of headaches away from the developer, however they should not be considered to absolve developers from understanding what goes on under the hood.
  9. SQL is indespensible...[ Go to top ]

    SQL is an indespensible tool in any java developers toolkit. If you are going to take time to learn XSLT, for God's sake, take some time to understand SQL and SQL tuning.

    Yes, raw JDBC can be a pain to work with. After a while or working with it and thinking "God this sucks", I went and looked at all the alternatives. Entity EJBs can be dismissed, of course, for any sort of complex object graph, and a mixed EJB/JDBC system strikes me a silly. Every OR mapping system I've looked at, from Coco to Toplink to OJB, foists too much config/xml editing on developers and usually still isn't flexible enough or fast enough. Seems that the OR impedence problem is real, and isn't going away soon, even with clever people on the case.

    After giving up on O/R tools, I've written my own simple light weight wrapper around JDBC, which allows me to do a few things:

    * Dynamically construct selects, which is useful when creating a general seach dialog.

    * Call PreparedStatement parameters by name, rather than by number, making code much easier to read and maintain.

    These two features (implemented in around 300-ish lines of code across five classes), when coupled with refactored "Result Set -> Object" mapping methods, seems about as good as O/R is going to get, to me.

    Good refactoring, a small and light weight JDBC toolset, and a middlin' to deep knowledge of SQL will kick the crap out of any expensive (usually in dollars, usually in terms of expressiveness, and always in terms of speed) generalized solution.

    Just my thoughts,
    Carson
  10. Eh...[ Go to top ]

    Perhaps "kick the crap" is too trollish. Let me amend that to "likely be easier to develop, maintain and scale".

    Woulnd't want to be a troll... :-)

    Cheers,
    Carson
  11. Eh...[ Go to top ]

    I've used O/R mapping tools since my C++ days. One of the problems I've always had with sending SQL statements directly to a database, as with JDBC, is that every error is a runtime error.

    No compiler in the world will catch a problem with this String:

       String myQuery = "SELCT * FROM CUSTOMER";

    Caching, connection pooling, optimistic commits - I don't want to be in the infrastructure business. I would much rather develop business applications, not middleware. Mapping tools are very useful, but once again, you've got to know about what's going on under the covers if the need arises (i.e. look at the SQL and figure out why problems are occuring).

    -Scott
  12. To continue...[ Go to top ]

    [quote]
     I've used O/R mapping tools since my C++ days. One of the problems I've always had with sending SQL statements directly to a database, as with JDBC, is that every error is a runtime error.

    No compiler in the world will catch a problem with this String:

       String myQuery = "SELCT * FROM CUSTOMER";
    [/quote]

    Eh, compile time is cheap. With ant it is incremental, and if you aren't using EJBs and are using a decent app server, you get hot redeploy of your classes. (Even with EJBs, it us usually just an undeploy, redeploy cycle.)

    Even with O/R tools, you can get column names or table names changing under you at run time. Chasing down this change in and xml file or a java file? Doesn't matter much to me.

    The small JDBC wrapper library I mentioned earlier (that, literally, *anyone* could write in an afternoon) eliminates problems like mistyping SELECT.

    [quote]
    Caching, connection pooling, optimistic commits - I don't want to be in the infrastructure business. I would much rather develop business applications, not middleware. Mapping tools are very useful, but once again, you've got to know about what's going on under the covers if the need arises (i.e. look at the SQL and figure out why problems are occuring).
    [/quote]

    Connection pools can and should be handled by a DataSource. No objection here. Caching is hard to do well, particularly when you are pulling large and complex object graphs out of a database. And, once you are clustered, you are fscked. And, if someone "goes behind" with a SQL tool, you are fcsked. Better, in my book, to let the database worry about caching. Database programmers write better code than us java monkeys anyway... :-)

    Transaction management is the only reason I can see using session beans for most Web apps. And even then, it isn't a braindead I-don't-have-to-worry-about-anything proposition. One run time exception gets through your try/catch block (or, you chuck a model exception straight through it from another method you call), and you've lost, with no ctx.setRollbackOnly() to save you.

    Better, in my mind, to know deep down what is going on, and take advantage of that power. Some abstraction on top of JDBC gives you much easier to use/maintain code. But general O/R tools fail, at least for my use cases.

    On the other hand, tool vendors have children to feed too...

    Cheers,
    Carson
  13. SQL is indespensible...[ Go to top ]

    I think SQL knowledge is quite valuable (I"ve certainly saved a couple applications by tuning my SQL), but the sophistication of mapping products have solved most problems which would take a medium sized team many months if not years to re-solve. Problems such as inversed relationships, class inheritance, SQL expression building are not trivial problems. Not to mention that most of the JDBC gains are not simple either (Connection pooling, PreparedStatement caching, optimized SQL generation, cursored ResultSets).

    I think JDBC solves a lot of problems for a lot of people. But calling it cost- and performance- effective is certainly not true for many complex projects. And while tuned JDBC is faster, native C would beat that hands down. But we're in the Java/J2EE world for a reason. Don't re-invent the wheel.
  14. more comments[ Go to top ]

    Steve,

    [quote]I think SQL knowledge is quite valuable (I"ve certainly saved a couple applications by tuning my SQL), but the sophistication of mapping products have solved most problems which would take a medium sized team many months if not years to re-solve. Problems such as inversed relationships, class inheritance, SQL expression building are not trivial problems. Not to mention that most of the JDBC gains are not simple either (Connection pooling, PreparedStatement caching, optimized SQL generation, cursored ResultSets).[/quote]

    I have to disagree. I've worked with all the major O/R tools, and even taken a stab a writing my own and, at the end of the day, in my experience, it ends up being about a wash. And, furthermore, as a project becomes *larger* and more complex, O/R tools fall apart faster. Inverse relationships? Moderately clever constructors. Class inheritance? <laugh/> Most O/R tools recommend you use *one* table for an entire class heirarchy. (Yeah, *that's* a solution.) As I mentioned before, I've created a simple JDBC wrapper that dynamically generates prepared statements. The entire library is about 500 lines of code, and I'm not a genius. It's not *that* hard.

    By the way, what do Connection pools have to do with this? Connection pools are part of JDBC. No sane developer would recommended that people roll thier own. It seems to me that a lot of people take poor programming habits, and use them as justification for expensive frameworks, rather than just suggesting that developers fix the poor habits.

    So some joe shmoe is opening a new connection on a JSP page. Fine. Point out to him that he should try to use a connection pool, and that he may want to migrate the SQL code to a backing class so that the JSP doesn't get junked up and hard to maintain. Unless you are a consultant, in which case $40,000 in Enterprise Software (tm) is clearly the solution.

    [quote]I think JDBC solves a lot of problems for a lot of people. But calling it cost- and performance- effective is certainly not true for many complex projects. And while tuned JDBC is faster, native C would beat that hands down. But we're in the Java/J2EE world for a reason. Don't re-invent the wheel.[/quote]

    As I said before, in my experience, it is O/R tools that start having problems in complex projects because, in complex projects, you have so many corner cases, and a general tool just can't handle them without an elaborate syntax. At which point, why not just use SQL? There may be some sweet spot in a project of middlin' complexity where an O/R tool is the cats meow, but the chances are low that a project will hit it: either its going to be a simple one off or, more likely, it is going to grow into a frankenstein of constantly changing and expanding requirements.

    Comparing java to c in this argument is silly.

    More and more, I think that the disconnect on these boards is between the guys who actually code, and the guys who "design" The "Iron clad requirements, an expensive and over engineered tool for every problem, and UML forever" set really starts to wear on me.

    Cheers,
    Carson
  15. more comments[ Go to top ]

    "Most O/R tools recommend you use *one* table for an entire class heirarchy. (Yeah, *that's* a solution.)"

    So what if they recommend this. You don't have to do it this way. There are three ways you can represent a class hierarchy in the DB:

    1. One table for all sub-types.
    2. One table for each sub-type.
    3. One table for each sub-type and a table for the super-type.

    All three have there pros and cons, depending on the situation (how much does each sub-type vary, how often will this structure change, etc.) I am currently evaluating Hibernate as a possible replacement for our home-grown persistance framework. Our hierarchy uses appoach #3. This is not what the Hbernate developers "recommend", yet Hibernate supports is just fine.

    What problems have you had with O/R tools and inverse relationship? What exactly do you mean by "clever" constructors?

    Ryan

    Ryan
  16. table inheritance[ Go to top ]

    TopLink will support all three of the above strategies
    out-of-the-box.
  17. more comments[ Go to top ]

    [quote]
    So what if they recommend this. You don't have to do it this way. There are three ways you can represent a class hierarchy in the DB:

    1. One table for all sub-types.
    2. One table for each sub-type.
    3. One table for each sub-type and a table for the super-type.
    [/quote]

    I guess I've just been too infected by the normalization nazis in our DBA group, and only really view #3 as an option. [shrugs/]

    [quote]
    All three have there pros and cons, depending on the situation (how much does each sub-type vary, how often will this structure change, etc.) I am currently evaluating Hibernate as a possible replacement for our home-grown persistance framework. Our hierarchy uses appoach #3. This is not what the Hbernate developers "recommend", yet Hibernate supports is just fine.[/quote]

    Yeah, hibernate looks pretty good. But, once again, I just can't see trading off error prone JDBC for error prone xml configuration as much of a win, and I feel that you give up quite a lot of power to do so. Just my taste, I guess, and I make no claims of genius.

    [quote]What problems have you had with O/R tools and inverse relationship? What exactly do you mean by "clever" constructors? [/quote]

    I haven't had *any* problems with O/R tools and "inverse" relationships. My point was that the inverse relation problem (assuming we are talking many-to-may) can be handled with a few hash tables and constructors that know about the relationship. Also, I would say that, in my experience, you are usually selecting off one base table, and joining out from it, so nasty many-to-manys don't bite you so hard.

    I should mention that I do hate JDBC. I just haven't found an O/R tool I like more, and I've made a sporting try at that.

    Cheers,
    Carson
  18. Check out JDX[ Go to top ]

    Carson,

    Apparently you have not tried JDX OR-Mapping product from Software Tree. Non-intrusive, flexible and easy-to-use.
    Gives you a lot of flexibility in object-modeling including class-hierarchies and associated mapping.

    Mapping is easy to define, modify and comprehend. No complex XML to deal with.

    Also sports a nice GUI (JDXStudio) to simplify mapping definition, schema creation and reverse-engineering of Java classes from existing schema.

    Small set of simple and consistent APIs. Powerful query facility.

    Fine-tuned, dynamic OR-Mapping engine. Use of connection pooling, prepared statements, minimal number of database round-trips.

    Lightweight and easy-to-learn.

    Patented technology. Market proven in small, medium and large scale projects.

    Affordable. Great ROI.

    As they say, "You have tried the rest, now try the best.". Free evaluation download of JDX available from the company web site.

    Cheers,

    -- Damodar Periwal
    Software Tree, Inc.
    Simplify Data Integration
    http://www.softwaretree.com
  19. Check out JDX[ Go to top ]

    *groan*

    Quite a list of buzzwords you got going there, my man. In fact, those are the claims that *all* the proprietary O/R vendors say.

    And why on earth would I want it to be proprietary? I'm evaling hibernate 2.0 beta 2 (due to this thread) again, and stepping through the code in debug mode using Eclipse. It gives me a really good idea of what is going on. (Side note: Hybernate 2.0 looks better than 1.x, but I still can see a lot of problems with it, and with O/R tools in general. Perhaps I'll post a summary of them at some point.)

    Cheers,
    Carson
  20. Check out JDX[ Go to top ]

    <quote>
    And why on earth would I want it to be proprietary?
    </quote>

    Well, there may be "proprietary" advantages of one solution over others based on its feature set/packaging/performance/ease-of-use and your application needs. Who knows, your needs may be best addressed by JDX. Or it may not be a good fit. Our customers had different choices but they liked and selected JDX.

    Peace.

    -- Damodar

    Software Tree, Inc.
    Simplify Data Integration
    http://www.softwaretree.com
  21. more comments[ Go to top ]

    OR mappers recommend flat table inheritance for performance reasons, not for application reasons. As SQL developers know, the fewer joins, the faster the operation. Connection gathering is a relatively high operation for high transaction count applications. PreparedStatements require careful allocation to gain the best performance. Does the average developer know these things, even being highly proficient in SQL? I think not, and even worse, the below-average developer (which is what most major commercial projects are allocated) are even less aware.

    OR Mapping software allows your application to be built rapidly, built in a stable manner, will be supported by a company or a larger user base, and allows you to deal with the application problem not some JDBC problem. OR Mapping software allows your application to grow organically, without having to go back into your application code to change every object with each schema change.

    And again, in my experience, maintaining raw JDBC in real applications is on the same scale cost and manpower wise as most C/C++ applications which provide far faster performance. You work at the exact same application layer (as most JDBC is a direct translation of C DB APIs) without any native code.
  22. more comments[ Go to top ]

    [quote]More and more, I think that the disconnect on these boards is between the guys who actually code, and the guys who "design" The "Iron clad requirements, an expensive and over engineered tool for every problem, and UML forever" set really starts to wear on me. [/quote]

    Carson-

    It's good that you wrote some code that handles your data access for you. I don't think you should extrapolate that experience to other systems, however. Your statement (quoted above) sounds pretty arrogant to me. I once did a white paper that discussed how to make a choice when you have to persist C++ data. The options were 1) homegrown persistence layer, 2) O/R tool, or use an 3) OODBMS. (This is obviously ancient history now.) There are always a lot of tradeoffs. You've said that you have used all the major O/R tools. Could it be that you did't take the time to give them a fair shot?

    -Scott
  23. more comments[ Go to top ]

    [quote]It's good that you wrote some code that handles your data access for you. I don't think you should extrapolate that experience to other systems, however. Your statement (quoted above) sounds pretty arrogant to me. [/quote]

    Damn. That's the exact opposite of what I was shooting for. I was aiming for "I'm a grunt and not a very clever one at that." I'll work on the tone. In general, I think that arrogance is the enemy of good programming.

    [quote]I once did a white paper that discussed how to make a choice when you have to persist C++ data. The options were 1) homegrown persistence layer, 2) O/R tool, or use an 3) OODBMS. (This is obviously ancient history now.) There are always a lot of tradeoffs. You've said that you have used all the major O/R tools. Could it be that you did't take the time to give them a fair shot?[/quote]

    As mentioned in an earlier post, I've taken a hard look at Cocobase, and OJB, and a passing glance at Toplink, and all of them had startup and scaling costs that I, in my admittedly brief (4 years now) experience in enterprise programming, found unacceptable. They just didn't, in the long run, pay off enough to justify thier use. My projects tend to be in the 30,000 to 50,000 lines of code range, so others may have different experiences, based on the size and needs of thier project.

    Also, I'm usually on a small development team (1-3 developers), another variable that might affect wheather on not an O/R tool is useful. (If you have a huge development team, it might be easier to standardize on a tool than to argue out who has the best ideas on persistence.

    Anyway, just presenting my view in what I hope is a moderately provocative and interesting way.

    Cheers,
    Carson

    P.S. Also, I should mention, I had a really, really negative experience with CocoBase's sales team, so that probably colors my opinion of that tool a bit. I try to stay objective about it though.
  24. more comments[ Go to top ]

    Carson-

    Thanks for the great discussion.

    [quote]P.S. Also, I should mention, I had a really, really negative experience with CocoBase's sales team, so that probably colors my opinion of that tool a bit. I try to stay objective about it though.[/quote]

    This is interesting to me. I had a great relationship with Cocobase and a really bad one with TopLink - and this was before TopLink was bought by BEA. The business relationship has a HUGE amount to do with tool selection in my opinion. Also, the project I'm currently on has about 25 programmers. You're right - this can definitely make a difference.

    Talk to you later.....

    -Scott
  25. Bitter Altenratives[ Go to top ]

    Good god!

    Come one Vic ! Once again, you are spouting generalities. I guess you really don't want to answer any of the REAL questions that anybody posts around here.

    What are the size of the projects that you are talking about? Are they all web-based? Please please put up some more quantitative information about why you think EJBs should never be used.

    Actually this all leads me to ask --> how many projects/times have you used or done industrial stregth EJB development ? (I am not talking about the recovery projects - there are so many boneheads out there who abuse EJB and other technologies).
  26. The 'Bitter Cost' of Enterprise JavaBeans[ Go to top ]

    Vic,

    it appears to me that you are the type of developer who has grasped a technology and refuses to consider anything different finding the weaknesses in new technologies to rationalize your arguments. I too tend to do this and have to remind myself every once and awhile to spend time evaluating these new technologies before passing judgment on them. It is not only easy to write bad EJB code it is equally easy to write bad JDBC code.

    I recommend trying Hibernate as a lightweight persistence framework. I use it exclusively in situations where remote access to EB's is not necessary. While Hibernate does not let you directly modify the generated SQL, it lets you output it to the console and modify the mapping files to optimize it. In addition Hibernate does not restrict you from using JDBC where it might perform better.

    I have used both both EJB and Hibernate appropriately in several enterprise level applications and I will not need to call you to recover them.

    KJ
  27. The 'Bitter Cost' of Enterprise JavaBeans[ Go to top ]

    KJ,

    I'd be interested to find out more about your experiences with EJB & Hibernate. I have done a lot of EJB work and I know the pitfalls and what not to do. Unfortunately I have not used any O/R tools such as Hibernate in a production setting. If you don't mind, can you send your email address to raju99 at hotmail dot com ?

    Thanks,

    Raju
  28. We use hibernate in a pretty mission critical B2B website. Runs flawlessly. No complaints.

    Cheers and big thanks to Mr. Hibernate,
         Henrik
  29. Thanks again[ Go to top ]

    Thanks again for some outstanding comments. Let me try to chime in here.

    - Re. inefficient SQL: I think that it's easy to make the case against inefficient SQL. You independent consultants know exactly what I mean. You'd be surprised at how many people still don't even connection pool. The most common performance scalability problems deal with round tripping and persistence (including native SQL). How many developers that work with you have ever bothered to run Explain on an access plan?

    While we're on the subject, it's even easier to make a case for hand-coded SQL once you layer on the complexities of a persistence framework. When you include a distributed caching layer and features like lazy-loading, it's quite common for a prepackaged persistence framework to beat pure SQL performance, for all but the most demanding cases.

    - Re. JBoss and selectable services, this is the direction that EJB needs to go. I make that point in the final chapter. Pluggable a la carte services with a model that moves toward AOP (like the JBoss interceptor model) are critical.

    - Re. commercial success with relational mappers, there's a reason that Oracle bought TopLink. We used TopLink at Contextual. It's a fantastic product. I'd be willing to bet that most early success with EJB used some form of relational mapper, or no persistence framework at all. If you look hard enough, commercial success with a mapper is easy to find. For success with JDO, check out the customer list on SolarMetric's web site. For really big time deployments on Wall Street, check out the customer reference from Persistence. And the TopLink market share dwarfed the others. (But we'll have to see what happens after the Oracle acquisition.) OO persistence plus an object domain is not necessarily a bad approach...EJB just hasn't gotten it right yet.

    In general, our take is that EJB has not gotten the persistence story right, but EJB is not just about entity beans. You can achieve pretty good success with EJB sessions/mdb with persistence alternatives.