BMP hands down. If it ain't broke, don't fix it.
As complex database access using CMP is very complicated and you have to manage many fine grained CMP's.
A self-proclaimed technology masochist, Rick often enjoys working with cutting-edge technologies. "Expect to bleed a lot if you are on the cutting edge", is one of Rick's favorite sayings. On a recent project that predates the EJB 2.0 specification, Rick and others adopted EJB CMP/CMR as there persistence layer of choice before the EJB 2.0 specification was finished.
Many a night, they doubted their decision, but it all worked out in the end. Rick states: "We did not want to use a non-J2EE compliant persistence solution, since we want the freedom of porting our application to other J2EE application servers, and the possibility of selling components that we created. In the end, it looks like going with EJB CMP/CMR was a good decision, but there was some pain along the way as we were using the specification a lot as our main form of documentation, and we were one of the first users of this implementation of CMP/CMR."
"We were able to help the vendor by reporting problems. Some of the problems were our perception of the specification versus the vendors perception of the specification. The vendor was usually right (that said we were credited with reporting (and one time fixing) quite a few bugs)."
"One of the advantages of this decision was our team got to work with a solid implementation of CMP/CMR a long time before it was available anywhere else. We now use EJB CMP-CMR for all projects. I am a big EJB CMP-CMR fan! This new feature will drive the adoption of EJB even further."
Since the team was practicing XP, they were able to come up to speed really fast on EJB CMP/CMR and EJB QL. Pair programming really spread the knowledge as each member learned and shared different parts of EJB CMP/CMR and EJB QL.