Howdy -- one benefit of CMP is that the bean, packaged into the DD, is not tied to the underlying database (so it's DB portable) although you'll still have to do the mapping in a vendor-specific way if you *do* change your database. The point is that you do not have to change any
Java code in your bean, and in fact you probably won't have to change the portable (i.e. non-vendor) parts of your deployment descriptor.
But perhaps the biggest benefit today is that CMP is nearly *always* found to be be faster in benchmark tests (like ecperf). This was true even with EJB 1.1, although most developers were initially surprised to hear this, and I believe even some folks on the EJB development team were surprised by just how positive the CMP results were, across most vendors. Although *you* can tune by hand with BMP, in most -- if not virtually *all*-- cases, the vendor is able to get in and out of the database with better performance overall. The vendor can, for example, gang multiple statements together. The vendor can use all sorts of native code tricks. They can do all sorts of the things that you do not have direct access to with BMP. With CMP, you're giving the vendor the opportunity to compete on performance, and they've been doing this VERY well since EJB 1.1. The problem with EJB 1.1 was the limitations on the O-R mapping. You couldn't necessarily do anything very sophisticated (depending on the vendor), and certainly not in a portable way, and because there were no local interfaces, it wasn't practical to have bean/bean relationships among entities. But now with CMR, wow, things have gotten SO much better.
There is far less reason to use BMP now that EJB 2.0 exists, although many developers still believe that it will always be more efficient to use BMP than container-generated code. But this simply has not been proven out by most of the benchmark tests. The whole model of EJB 2.0 (like the abstract getters and setters, for example) now gives the container vendor a much easier way to do, say, dirty detection and lazy loading, and so that's no longer an advantage that BMP has over CMP. Although not strictly *required* in the spec, virtually all vendors that matter are taking advantage of every performance trick they can in the interest of making CMP worth it.
OK, I know I sound like a CMP cheerleader. And I probably am. But in a project I did at Sun, we had a hard time coming up with customers who were using BMP for performance reasons with EJB 2.0. And in most of the examples that I saw, professional services were able to prove to them that CMP turned out to be a better choice.
This is the main reason that BMP is not part of the EJB 2.0 developer certification exam.
cheers,
Kathy
