Java Tutorial - Java Scipt : Bean-Managed Persistence

Java Tutorial - Java Scipt :

Bean-Managed Persistence


Bean-managed persistence is the catchall fallback EJB to data sources. By leaving the code to work with the data in the hands of the developer, BMP is both extremely powerful and limited at the same time. The premise behind the EJB container is to simplify the development of enterprise components; the result, though, is that by dropping back into hand-coded persistence, many of the benefits of container management are lost. The analogy we like to use is that BMP is to persistent components as Java Native Interface (JNI) is to Java. Sure, there are times when we need to access things at a lower level but it is contrary to the spirit of the architecture. Our advice to you is to take some concrete benchmarks and verify that there isn’t a more elegant way to do things before diving into Bean-managed persistence. One huge drawback to BMP is the way the interface is specified. Namely, BMP manages on a per key basis. This means that retrieving each BMP bean will have to incur the overhead of an entire roundtrip. This translates to a 1+n database query overhead. For example, let’s say we have a BMP bean that models a customer object and uses JDBC to persist itself. If the client uses the finder and locates 100 customers, then 101 database queries must be used. To give a sense of the inefficiency of this, the same thing can be accomplished in a
single database query. The consensus view in the industry is that BMP is a legacy technology now. It still has a place within the J2EE framework, but it is getting squeezed out by more appropriate solutions such as CMP and Java Data Objects (JDO). Often a stateless session bean facade to JDO or JDBC can be substituted for a BMP and
get you more bang for the buck. Also, keep in mind that with CMP, the EJB container can make these optimizations and you have the added benefit of not needing to hand-code the solution. Be sure to check out the changes in CMP
2.1 before dismissing CMP, because it is much improved over the justifiably maligned CMP 1.0.