First page Back Continue Last page Graphics
...BMP vs. CMP
Why manage persistence in bean?
- Bean may use features not available through CMP
- Bean may represent an aggregation of data
- Bean may require explicit control over data access
- Examples:
- To use a non-JDBC datasource
- To implement custom caching of data
The basic approach:
- Code the bean class to handle persistence
- Tell the DD that bean is managing persistence
Notes:
Why manage persistence explicitly if it is so much easier to let the container do it? Because CMP may not have the features you need. Here are two hypothetical situations that would call for BMP:
Your data source does not support JDBC. Most EJB server products use JDBC to talk to the chosen database. If that’s not possible and you must use a proprietary means (such as a custom native library or direct, low-level socket manipulation), you will have to do it through explicit code.
The bean represents an aggregation of entities that live in multiple tables. For example, an Order entity bean that represents the order plus the line items.
You want to implement special caching of data. Say the entity bean represents an entity such as company departments. Assume department data rarely changes. The table has a fixed, limited number of rows, and no updates are performed. For performance, you want to keep a department’s data in memory once it is first used. You could not force the container to keep a bean instance in memory for every department. But you could have the bean put a newly loaded department in cache. Then, when a client asks for a department, the bean could first look for it in cache.