Why should I avoid Bean Manage Persistence?
Performance issues with BMP
The principle problem with BMP is that it results in n+1 trips to the database. The finder and every row will involve a separate trip to the database. Couple this with transactions and you have all of the makings of a severe performence problem.
Alternatives to BMP
Use CMP - CMP will give you access to caching, transaction locking, and all of the services available to persistent components in the appserver. Additionally, CMP allows you to avoid being tied to a particular database. You can UseBMPFindersWithCMPEntities.
Use Stateless Session Beans and Value Objects - if you absolutely cannot use a persistence engine, use Stateless Session Beans + JDBC to your database as opposed to BMP. You won't be able to take advantage of appserver based locking, and you will be tied to a particular database, but the performance characteristics are much better. You will avoid the n+1 problem.
-
When considering BMP it is very important to realize that its performance characteristics involve n+1 trips to the database. Performance tuning in CMP can create scenarios of equal or better than (depending on cache semantics) JDBC. This being said, if it is not possible to use CMP it is generally preferable to avoid BMP entirely and go straight session beans/value objects/jdbc.
references:
This is not unique advice from JBoss, you'll receive the same advice from competitive offerings:
"
If you choose to use a BMP entity EJB when a CMP engine or a stateless session EJB with JDBC could be used, you're taking an unnecessary performance hit. A BMP entity EJB doesn't come without the overhead of container management, server management, and (sometimes) unnecessary life cycle migration.
"
"
BMP cannot avoid the n1 problem: One of the problems that plagued CMP engines with EJB 1.1 was the n1 problem. This was caused by containers that required n+1 database queries and network invocations to load entity EJBs in a parent-child relationship. For example, if you had an Order entity EJB with 1,000 LineItem children entity EJBs in a one-to-many relationship, EJB 1.1 CMP engines would require 1,001 database queries to load all of the EJBs. This is crazy, since it's likely that all of the data was stored in only two tables.
"
"
Another feature of CMP that makes it attractive is its ability to manage optimization of the set of SQL calls that must be made in order to read or write the persistent state of an EJB. For instance, the CMP model in WebSphere AE allows a set of Entity EJBs to be read from a relational database in a find() method with only a single SQL SELECT call. This is much more efficient than the default BMP case, which requires N+1 SQL calls to do the same thing, unless some complex caching scheme is used (which will be the subject of a future article).
"
(note that the cache thing is rather strange advice)
-
Related:
Referenced by:
Comments