Java Tutorial - Java Scipt :
Container-Managed Persistence 2.1
CMP 2.1 addresses many of the issues that limited earlier releases of CMP (namely CMP 1.0) from being accepted by developers. The end result is that CMP 2.1 can be used for complex data mappings to the EJB model in an efficient manner. CMP 2.1 tries very hard to bring back into the fold concepts that have worked well in databases and integrate them into the component model. There is still an impedance mismatch between the two worlds, but it’s nice to see the signs of reconciliation. Specifically, the 2.1 specification added support for the following features:
Relationships. Now, in addition to managing beans that map to records within individual tables, the container has the ability to manage relationships between beans representing data from multiple tables. This relationship
management was left to the programmer prior to the EJB 2.0 specification.
Abstract interfaces. Abstract interfaces are a great boon for the EJB container. By having abstract getters/setters, the EJB Container can intercept method calls. This is beneficial for both passively gathering access pattern statistics and for actively manipulating the call. In the older 1.0 specification, access to raw fields was allowed, making it much more difficult for the EJB container to get involved.
The EJB Query Language (or EJB QL). The EJB Query Language is an improvement over the limited and tedious finders in the 1.0 specification. EJB QL draws heavily from SQL, which makes it easy to pick up and ready to apply to solve real-world problems. On some level, it feels wrong to have parallel technologies that are so similar, but the bottom line is that EJB QL is vital to making CMPs independent of the underlying database.
Dependent classes. Dependent classes are important for aggregation. Often it is nice to model contained items without the costs of a heavyweight EJB. For example, an Order EJB might consist of one or more line items. Prior to the dependent classes, each of those would have had to be modeled as its own EJB. This modeling was inefficient, difficult to manage, and made CMP more difficult to use in earlier version of the specification.
Cascading deletes. Cascading deletes are important for maintaining relationships between objects. When a parent object is deleted, the deletion is cascaded to the child objects.
Automatic primary key generation. Automatic primary key generation removes the burden of generating unique primary keys from the application. This task can often be delegated to the native database for greater performance, while maintaining key integrity. Cascading deletes and automatic primary key generation are also concepts
borrowed from the relational database world. CMP beans still have extra, but normally negligible, overhead. There are many declarative deployment options that can drastically change the performance profile of your enterprise application, depending on how the CMP is used within the J2EE application. For example, if updates are minimal, then the CMP can be more aggressively cached.
CAUTION
These declarative options can also be dangerous. For example, specifying the wrong type of caching has far-reaching consequences beyond just reducing performance—it is actually possible to undermine transactional
correctness! This type of issue is not limited to CMP beans, but is mentioned here to remind us that declarative options can add complexity outside thescope of the code.
A counterintuitive result of all this is that CMP EJBs can actually be faster than handcrafted persistence code in the grand scheme of things because the container is able to use the deployment hints along with runtime behavior to
optimize data access. Because the EJB container knows the relationships between data and the access patterns, it can act as a smart cache. To analogize, the effect is that the EJB container can do for data what the HotSpot JVM does for code. As always, though, your mileage may vary.
