To CMP or not to CMP....that is the question!

Discussions

EJB programming & troubleshooting: To CMP or not to CMP....that is the question!

  1. To CMP or not to CMP....that is the question! (4 messages)

    Hey guys.
    I have a problem which I am hoping you can help me solve.

    Let's say that we are designing a simple J2EE address book web application.
    The application design must follow these requirements:

    1. The application stores all data in a relational database.
    2. The user interface to the application is browser based only.
    3. The application must be independent of the database type (Oracle, MS Sql, Informix).
    4. The application must be independent of the application server type.
    5. The application must be portable between databases and application servers.

    The application allows the user to do the following:

    A. Search for entries in the address book
    B. Display (read only) entry details
    C. Add/edit/delete entry

    Now, what I'm wondering is: Should we use CMPs to encapsulate the address book entries, or should we use Java classes with JDBC access to the database (managed through session beans)?

    I know that if we use CMPs, we don't have to code the database access calls.
    Not only does this approach save us time, but it makes the bean portable across various database servers.

    But if we use CMPs, it seems to me that we face the following problem (please correct me if I am wrong):

    The application server creates tables in the database for storing the CMP data. The names of these tables are not specified by the J2EE specification (because the persistent storage does not need to be a relational database). Therefore if we deploy the application on application server A, and then later decide to change to application server B, then B might have other naming rules for tables than A (and would therefore be unable to read the data from the database).
    Therefore, by using CMPs, our application is no longer portable between application servers, and this violates design requirement number 5.

    Now, I know that many application servers allow you to specify a mapping for CMP to an existing table, but the configuration files for specifying these mappings are different between application servers. And since we do not want our application to have to know anything about the server it is to be deployed on, that solution is unacceptable.

    Another way would be to implement the address book without CMPs, using Java classes with JDBC access to the database (caching frequently accessed data, perhaps with the A.C.E. Smart Cache pattern).

    My question is: What exactly is the tradeoff between these two implementations (in this limited web access only context)?

    Will the non-CMP implementation come in second in performance (and if so, why?)?

    When the application server tier is clustered, does the application server synchronize the cached CMP data in the cluster? This will have to be done manually in the non-CMP implementation.

    Any thoughts on the above issues are greatly appreciated.

    Thanks.
    OGG.
  2. By 'using Java classes with JDBC' are you referring to BMP or just plain old classes with JDBC calls? Why not use BMP.

    For spec 5 a simple factory pattern (see PetStore) for database portability.?

    So far I've hated CMP on every server I've worked with, although I haven't yet worked with ejb 2.0, so maybe my opinion will change.

    -Newt
  3. But why should I use BMP instead of just plain classes with JDBC access? BMP is much slower than CMP, and what benefits are there to using BMP in this context?
  4. bmp allows you to code your database calls for optimization. there is no guarantee that the app.server will optimize the database call except for itself. now, the point is how many appservers optimise the database calls and how well they work with different databases.
    further if there is indeed a prob with the cmp, you will hava an extremely hard time figuring out what went wrong. in a nutshell you will have a hard time localizing the prob.

    vijay
  5. Popular beliefs are that CMP Entity Beans are slow and cumbersome and not as optimized as BMP Entity Beans or even plain Stateless Session Beans making JDBC calls. That might be true for predecessors of EJB 2.0. I'm not too sure whether EJB 2.0 will change the landscape.

    At least, Tyler Jewell thinks so:

    http://www.onjava.com/pub/a/onjava/2001/12/19/eejbs.html