…consider the strengths in performance and reduction in development that can be added by leveraging a high-quality CMP container as opposed to developing data access logic using a BMP architecture. I guarantee you’ll be happy with the results.

Excellent post! I couldn’t agree more, the debate mirrors the one around the merits and usefulness of automatic garbage collection. Sure you can manage memory yourself, but how much are you willing to pay for that vs. the performance hit you’d take in a garbage collected environment.

One issue that comes up often in this debate is the quality of the underlying SQL generated by CMP containers. The problem stems from the fact that one has very little, if any, opportunity to tune the generated SQL, and that it’s usually an all or nothing proposition. Hibernate, and to some extent Toplink, have attempted to address this but there’s still a long way to go for CMP containers to bridge this gap.

“… an important part of the J2EE specification, EJB persistence, has long been criticized for its complex development model and for poor performance of entity beans. It’s pretty much accepted as fact that if entity beans (especially container-managed persistence entity beans, or CMPs) are going to be used in an application, performance will suffer. This is not true.”

[The article] “focus[es] only on concurrency and long-term caching strategies for CMP entity beans” and “briefly cover[s] improvements available in the most recent version, BEA WebLogic Server 9.0.”

dev2dev: Peak performance tuning of CMP 2.0 Entity beans in WebLogic Server 8.1 and 9.0

Technorati Tags: Java| CodePerformance