Skip to Content

Introduction :

Both CMP beans and JDO are persistent mechanisms from J2EE which have features to store persistent objects that should be consider before committing your code or project .Many of us know them well. I thought of comparing them here.

JDO persistent classes are suitable for modeling persistent instances in an application server are typically used behind an Enterprise Bean.CMP beans are typically used behind session beans but their remote behaviour is rarely used. .

JDO persistent classes can be used without recompilation in any tier of a distributed architecture and can be debugged in a one- or two-tier environment prior to integration into a Web Application server. CMP beans can be debugged only after deployment into the Web Application server. .

Unlike servlets, JSP pages, and EJB components, there is no built-in remote behavior with JDO classes. All of the distributed, transaction, and security policies are based on the single Persistence Manager(PM) that manages all of the persistent instances of your business logic. This means that JDO persistent classes can be used in any tier of a distributed application. .

CMP beans give you a high degree of portability across application servers. The bean class and required deployment descriptor are standard (J2EE specification for EJB and web.xml). Most of the incompatibilities between implementations are found in unspecified areas of mapping beans to the underlying datastore, optional features such as read-only beans, and extensions in deployment and management of beans.

With CMP, you identify every bean class, persistent field, and persistent relationship in the deployment descriptor ie web.xml. Using JDO, you identify every persistent class in the metadata, but you can usually take the default for the persistence of fields, including relationships that we normally do in a .map file. .

With CMP, relationships are managed; this means that during the transaction a change to one side of the relationship immediately affects the other side, and the change is visible to the application. JDO does not support managed relationships, although some vendors offer them as optional features..

Inheritance is a common paradigm for modeling real-world data, but CMP beans do not support inheritance. CMP makes a distinction between the implementation class and the bean. The abstract bean-implementation classes and the local and remote interfaces can form inheritance relationships, but the CMP beans that model the application’s persistent classes cannot. Relationships in CMP are between CMP beans, not implementation classes, and these relationships cannot be polymorphic. .

JDOQL and EJBQL provide similar access to data in the datastore. Both allow you to select persistent instances from the datastore to use in your programs. Both use the read-modify-write pattern for updating persistent data. Neither language is a complete data-manipulation language; both are used only to select instances for manipulation by the programming language. .

Comparison of JDO and CMP Beans :-

Having seen some of the features of both JDO and CMP, now it becomes meaningful for us to compare them in various front of usage. The below tabular column gives us an idea of the characteristics of both of them.

style=’color:black’>Characteristic

style=’color:black’>CMP beans

style=’color:black’>JDO

style=’color:black’>Environmental style=’color:black’>

style=’color:black’>Portability of applications

style=’color:black’>Few portability unknowns depends on the container.

style=’color:black’>Documented portability rules

style=’color:black’>Operating environment

style=’color:black’>Application server

style=’color:black’>One-tier, two-tier, web server, application server

style=’color:black’>Independence style=’color:black’> of persistent classes from environment

style=’color:black’>Low: beans must implement EJB interfaces and execute in server container

style=’color:black’>High: persistent classes are usable with no special interface requirements and execute in many environments

style=’color:black’>Metadata style=’color:black’>

style=’color:black’>Mark persistent classes

style=’color:black’>Deployment descriptor identifies all persistent classes

style=’color:black’>Metadata identifies all persistent classes (.map files)

style=’color:black’>Mark persistent fields

style=’color:black’>Deployment descriptor identifies all persistent fields and relationships

style=’color:black’>Metadata defaults persistent fields and relationships

style=’color:black’>Modeling style=’color:black’>

style=’color:black’>Domain-class modeling object

style=’color:black’>CMP bean (abstract schema)

style=’color:black’>Persistent class

style=’color:black’>Inheritance of domain-class modeling objects

style=’color:black’>Not supported

style=’color:black’>Fully supported

style=’color:black’>Collection style=’color:black’>, style=’ color:black’>Set style=’color:black’>

style=’color:black’>Supported

style=’color:black’>Supported

style=’color:black’>List style=’color:black’>, style=’ color:black’>Array style=’color:black’>, style=’color:black’>Map style=’color:black’>

style=’color:black’>Not supported

style=’color:black’>Optional features

style=’color:black’>Relationships

style=’color:black’>Expressed as references to CMP local interfaces

style=’color:black’>Expressed as references to JDO persistent classes or interfaces

style=’color:black’>Polymorphic references

style=’color:black’>Not supported

style=’color:black’>Supported

style=’color:black’>Programming style=’color:black’>

style=’color:black’>Query language

style=’color:black’>EJBQL modeled after SQL

style=’color:black’>JDOQL modeled after Java Boolean expressions

style=’color:black’>Remote method invocation

style=’color:black’>Supported

style=’color:black’>Not supported

style=’color:black’>Required lifecycle methods

mso-bidi- color:black’>setEntityContext style=’color:black’>, mso-bidi-color:black’>unsetEntityContext style=’color:black’>, mso-bidi-color:black’>ejbActivate style=’color:black’>, mso-bidi-color:black’>ejbPassivate style=’color:black’>, mso-bidi-color:black’>ejbLoad style=’color:black’>, mso-bidi-color:black’>ejbStore style=’color:black’>, mso-bidi-color:black’>ejbRemove style=’color:black’>

style=’color:black’>no- arg constructor (may be private)

style=’color:black’>Optional lifecycle callback methods

mso-bidi- color:black’>ejbCreate style=’color:black’>, mso-bidi-color:black’>ejbPostCreate style=’color:black’>, mso-bidi-color:black’>ejbFind style=’color:black’>

mso-bidi- color:black’>jdoPostLoad style=’color:black’>, mso-bidi-color:black’>jdoPreStore style=’color:black’>, mso-bidi-color:black’>jdoPreClear style=’color:black’>, mso-bidi-color:black’>jdoPreDelete style=’color:black’>

style=’color:black’>Mapping to relational datastores

style=’color:black’>Vendor-specific

style=’color:black’>Vendor-specific

style=’color:black’>Method security policy

style=’color:black’>Supported

style=’color:black’>Not supported

style=’color:black’>Method transaction policy

style=’color:black’>Supported

style=’color:black’>Not supported

style=’color:black’>Nontransactional style=’color:black’> access

style=’color:black’>Not standard

style=’color:black’>Supported

style=’color:black’>Required classes/interfaces

mso-bidi- color:black’>EJBLocalHome style=’color:black’>, local interface (if local interface supported);

mso-bidi- color:black’>EJBHome style=’color:black’>, remote interface (if remote interface supported);

style=’color:black’>Abstract beans must implement mso-bidi- color:black’>EJBEntityBean style=’color:black’>;

style=’color:black’>Identity class (if nonprimitive identity)

style=’color:black’>Persistent class;

mso-bidi- color:black’>objectid style=’color:black’> class (only for application identity)

style=’color:black’>Transaction synchronization callbacks

style=’color:black’>Not supported

style=’color:black’>Supported

Conclusion :

The above blog gives us an idea to choose the respective Persistence framework component required for storing persistent Java objects. So when you want to go for persistence next time in your project, JDO or CMP you decide !!!

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Klaus Meffert
    As the public review of JSR 243 (An Extension to the JDO specification Public Review Ballot) at http://jcp.org/en/jsr/results?id=2997 indicates, JDO was rejected majorly and could be seen as failed.

    The comments on the JSR site are quite interesting and tell a lot about the current problems involved with JDO.

    The result of the public review seems not to be a commercial for JDO.

    (0) 

Leave a Reply