CMP (grunt) what is good for? Absolutely nothing.. say it again


EJB design: CMP (grunt) what is good for? Absolutely nothing.. say it again

  1. I have been reading this forum for a while, I have answered some of your questions, and tried to solve some of your problems. I have been reading a lot of new EJB'ers asking questions about CMP especially now with the New and improved EJB 2.0 specification fresh off the press. With this latest rendition of the spec we now get CMP with dependent value classes that are supposed to solve some of our dependant data needs. And I ask why? Why do we need this? Did all of the programmers in the world forget SQL? Is SQL a bad word? Is it really that complicated to perform a select, update and insert? Or are there just a shortage of good programmers out there and this is the easiest way to take a marginal developer and turn them into a wizard, “Jeez Johnny you accessed every table in our database and displayed all the results in less than 5 days…. Sure it takes 2 minutes to update the employee record but it is done, good job Johnny you get a raise.”

    Does anyone else have a problem with this? I will give you an example, with the new EJB 2.0 spec out I created a CMP, I wanted to see what all the fuss was about, maybe I am loosing it, maybe this is the way of the future, maybe I could improve my code throughput by a couple lines a minute, hey I am a professional I want that edge as well as the next guy, so what the heck lets give it a try. OK who invented this crap? Ever try to create a finder method? Try creating 3!!! I created my BMP bean in the same amount of time, and then I created 3 more BMP beans, since I was using the DAO pattern, in half the amount of time it took me to create the 3 additional CMP beans. Ok there went my improved lines of code per minute stat. Alrighty, lets run them and see who out performs whom, hmmm why does my BMP beans work faster? Sure grant it just slightly faster, so I changed them in a blink of an eye to stateless session beans (since I was using DAO that was easy), and presto they were 2 times faster.

    So my question to all of you is why? Why use CMP at all? Why have it in the spec? Why don’t we just say opps, that doesn’t really work we screwed up forget about that and lets move on with our developer careers? I am seeking answers please help me.


    Threaded Messages (19)

  2. You are absolutely right. I see no value whatsoever. Unfortunately, this attitude towards CMP may limit your employment choices. Afterall, if a hiring manager reads that CMP is the sh*t, he wants CMP. It's kind of like the "Emporer's New Clothes".
  3. Are you complaining about entity beans in general or just CMP entity beans? Sounds like you want to hand code your persistence...I don't...

    Tinou Bao
  4. I agree. I have done testing on three different application servers with CMP/BMP, and because of the results, I have decided to pretty much always use BMP!
    CMP is pretty much worthless to me. On top of that, I've had to do a lot more re-configuring to re-deploy CMP beans to different servers 'cuz they each have their own little way of managing it with config or props files. Even if it does take more time to do BMP (which it maybe didn't for you), I would still use BMP over CMP.

    I'm with you man.

  5. I guess they do the breaks for you. Probably if I'd read the directions on the right.......
  6. I have the same experience. I found the BMP to be much more
    powerfull and flexible for non trivial applications. It allowed me to have better control with on demand loading
    and slective updates. This is especially true when the entity beans modelled complex business object mapping to multiple database tables.

    Pranab Ghosh
  7. How about this? If you can do everything with BMP then why not go for Stateless Session Beans? You can acheive anything you want with it too. And it scales the best way too.

  8. You may find some interesting perspectives on CMP here:

    IMHO the biggest benefit of CMP is the vendor specific optimization for database calls. For example in BMP if you don't use something like a "Fat Key" pattern you have to make n+1 database calls when calling findByXXX(), whereas using CMP and specifying <finders-load-beans> in the deployment descriptor you avoid subsequent n number of calls.
  9. Sorry, but I doubt that a good CMP engine is slower than BMP. With EJB 1.1 maybe (although you should maybe try BAS 4.5), with EJB 2.0 never, unless you do many hours of tuning for every bean... something I don't want to do.
    And now with local interfaces I don't see any reason using BMP (other than connecting a legacy system) because you can model OO now. You'll need BMP if you first design the database, then the application (and this should only happen with connecting legacy apps).
    Some appservers apply many very clever strategies to make CMP beans faster, and with some servers they even work ;-)
    The next thing is relationships in EJB 2. They don't really work with BMP, and hey, they are really cool.

    kind regards

  10. Okay, guys, let's put some points over "i".
    1. First of all, concerning recent posting. You do not need CMR in BMP, that's because you code your own CMR.

    2. Session Beans vs Entities. Yes, they will rule but only for reading operations (that transactional anaware). You'll need to write your own transactional engine (I don't think it will be better than AppServers' one, though) to support database writing operations.

    3. We have a lot of O/R mapping tools, but they cost money and sometimes even they do not solve our problems.

    4. Okay, I came to the following solution for really BIG systems with hundreds of tables and entities.

    We create BMP beans that are the same inside - we use dynamic attributes, BMPs doesn't need to know attributes names, they deal with collections. We also create DAO pattern for every entity, but they differ not much too. We use views to escape problems with relations and stored procedure for writing/updating database functions. So, for most of our beans the only thing we change are names of the views and stored procedures in DAO. With creating our special EJB generator (currently in process), we plan to achive the production of 10-15 entities an hour without any problems. And they work pretty faster than CMP.

    Forgot to mention that all of our BMP's are locally configured and wrapped by "controller's" session stateless beans, which provide basic communication (via XML files, I think we will use SOAP soon) with centric servlet which provides XSL transform and output real data to JSP "views".

    So, what guys do you think about that kind of concept?

  11. 2. Why do you need to write your own transaction manager?

    Granted, you need to be bit more careful, but it's nothing too difficult.

    You let the container handle the transaction.

  12. I think the suggested concept is pretty nice for some systems, though I cannot really comment it as I would have to try for myself.
    My only objection now is that it is more complicated than using "simple" CMP, because even if you use generators you will have to maintain the code, unless the tool is completely "2-way"... and still, there is more code to read.
    I however wanted to comment on CMR: I don't think "You don't NEED CMR" is the right conclusion, you CANNOT DO CMR would be better in my opinion because:
    1) CMR is easy to use, just say getRelatedBeans() and you'll have a collection of remote interfaces. With your own relationships you'll either need to store a handle or do a findByPrimaryKey() for the target EBs... while this is the same the appserver does (the appserver may be able to optimize it) it is more coding.
    2) CMR allows one to one, one to many etc. relationship rules. If you have a CMR 1-1 A-B and you do a A.setDep(C) the dependency flag of B will be cleared automatically. This is a _huge_ advantage as bidirectional relationships have been quite q problem in "clean" OO design, most "gurus" suggest using an intermediate object, which is not quite convenient.

    So all I say is that both CMP and CMR are definitely more convenient than other methods of persisting (may it be O/R, BMP or something else)... and in my experience CMP/CMR is in most cases faster than BMP/BMR, at least it is not that slower.
    This is the main reason I prefer it: It makes development faster for "simple" DB persistence (for connecting legacy apps you'll have no choice whatsoever). For the time saved I can easily buy a second box.

    kind regards

  13. I agree with Rick, Session beans use the same transaction manager in the container as Entity beans. Furthermore, session beans have more flexibility with the container where they can be Bean managed. Entity beans can only be Container managed. Session beans can be both container managed and bean managed. If you know SQL and performance is very important, I highly recommend managing the database with a stateless session bean. SQL realy isn't that hard to use. Yes, its a takes a little longer to write and a little more error prone, but it is worth it in the end. We just converted a system session-entity to session-session, where the database was managed with stateless session beans and the performance sky rocketed. I wouldn't have believed it if I hadn't seen it with my own eyes. We had benchmarks for both scenarios as proof.

  14. By the time you have implemented ALL the extra features in entity beans that are not available in session beans, I doubt you will see much performance gain left. As an example, how do you control web-based users accessing the same database record in a stateless session bean? You have to write a whole bunch of code yourself and you might just as well use an entity bean.
  15. Eric,

    The scenario you describe has users accessing the same record from a database. Do these users have the ability to edit the same records or are they reading only?

    I've been in IT for quite some time and I have yet to come across a situation where two users need to update the same record. Therefore I've never needed any sort of record locking scheme and many of the features of entity beans. If I ever do encounter a need for this I would much rather allow both users to insert new rows instead of updating the same record. This form of auditing is a requirement of many of my clients.

    Stateless Session Bean data management works for me. I like the performance and at this point, have no need for Entity Bean feaures.

  16. Jeff, now we are way off topic here :-)

    Believe it or not, every time I was asked to develop a Web application (mostly intranet) I was asked what if two users happen to update the same record. My standard answer has always been that without spending major effort to check the currentlyness of the data, the user who clicks the submit button the last would win. I know in real-world this probably does not happen that much, but I was always asked to prevent it, if it is simple enough to do. Yeah in an e-commerce situation where only the wife in a household is allowed to make a purchase on the internet this will never happen.

    I don't want to dwell on the necessity of having entity beans. The Java Server J2EE Ed. book from Wrox has a nice section on it.

  17. Sorry to dwell on about this, but it is (sort of) EJB design related ...

    In the scenario you describe with 2 users updating the same record, how does using any entity bean give an advantage over a stateless bean?

    If I read it correctly, 2 users ('clients') both initially read the same row of a table via an entity EJB, and after a period of time, both do an update, again via an entity EJB.

    The way I see it, after the initial read, the transaction would end and all locks would be released. When each user then 'commits', another transaction would begin on each client, and both updates would take place, regardless of whether you are using Entity or Session EJB's. Or am I missing something?

    The only way I could see the lock being maintained would be if the client did the read/update within 1 transaction, ie. using the same 'instance' of an Entity EJB. But I wouldn't have thought this would be particularly good design, as the user could wait for an hour before making his/her mind up :-)

  18. Kent,

    This system that you converted from session-entity to session-session, what persistance were you using for the entities?
  19. Ok i just want to clarify one point, i did not say ENTITY beans are not good for anything, i said CMP (container managed persistence). I was not arguing that you should do everything with in a session bean (or at least not now.) What I am saying is that there CMP is basically useless, and to respond to the one person that says CMP is optimized more than BMP .. i say NO WAY!!! First it can't do joins, so what could it possibly optimize? I don't think the container developers are trying to force us to use CMP by making the JDBC drivers faster in one than the other, first they both use the same connection pools.

    Any way my point was to try to come up with scenerios where CMP made sense, to try to unconfuse a confusing issue.

  20. I think we were on topic until the 1st post dated 7/12/2001.

    As for CMP vs. BMP, you have to understand "optimization" in a broad sense, not just WRT executing a SQL or implementing complex relationships/joins. Try to think in light of the complete entity life cycle and all the container callbacks. CMP allows a container vendor to implement proprietary stuff to cut down the number of such calls. In BMP, you normally don't have this kind of luxury, unless you follow certain design patterns. BTW, have you read the article/posts at the links I provided?