Debu Panda has written up some guidelines on how you can optimize CMP entity beans with relational databases. He shows you how to reduce database operations, tune database/sql access, use caching in the middle tier, and choose the right concurrency mode and locking strategy.

"Every body shuns CMP entity beans be either they try to blame J2EE or get some political mileage for their unveiled agenda. This happens (in) almost every thread at least in community forums like TheServerSide.com or JavaLobby. However I was surprised to see a houseful when I presented "Optimizing Container Managed Persistence with Relational Databases" with Mike Keith in JavaOne this year. I was expecting very few attendees with (the) ongoing slaughter of CMP entity beans in the community forums and the fact that EJB is having a quantum leap in the EJB 3.0 spec. And almost everyone stayed in the room. After the presentation, I spoke to (a) few attendees and almost every one of them use CMP entity beans in their production application servers such as Weblogic, OC4J or Websphere..."

Read Optimizing CMP Entity Beans with Databases

Interesting and useful article for existing CMP users. More importantly, some VERY useful warnings for anyone considering using CMP for a new application.

Reducing database operation or number of SQL generated by CMP entity beans is easier said than done!

That's the first warning out the way.

Several EJB containers cannot rely on the existence of primary key constraints in the underlying database table and executes a SELECT statement to make sure the insert does not lead to a duplicate entry.

Hmmm... nice and efficient

Creating an entity bean with a relationship is a two-step procedure, by default this involves two SQL statements: an INSERT statement in ejbCreate() to persist the entity bean, and an UPDATE to establish the relationship.

There's a theme developing here ..

Association tables are maintenance nightmare and require unnecessary SQL statements and JOIN between the entity table and association tables to maintain relationship

Do we really want to remodel our database to cope with CMP? I'm not sure how we are going to model many-to-many relationships without association tables ..

I hope I don't sound critical of the article - some very good points have been raised. It's just that I was responsible for the implementation of a CMP container many years ago and was shocked at the inefficiencies involved. I've been a convert to DAO ever since!

Cheers,

Andy Grove
Code Futures

Association tables are maintenance nightmare and require unnecessary SQL statements and JOIN between the entity table and association tables to maintain relationship
Do we really want to remodel our database to cope with CMP? I'm not sure how we are going to model many-to-many relationships without association tables ..

>> This recommendation was for 1-M. You have to use an association table for M-M. I changed this in the original blog

-Debu

I thought optimistic concurrency with cache-between-transaction rocks , atleast in weblogic 8.1 in most cases. Except that there were problems with CMRs...is there a bug ? :-(

Does bc4j provide for programmatic cache invalidation like weblogic. (WLCacheHome)
But even here i think WLCacheHome is only for read only / read mostly pattern beans and not for normal read/write beans. The problem we had was that we used jdbc / cmp mix and since we were using cache-between-transaction feature we c'd not let the cache know that something has just happened and that the data has gotten through from the backend.

Weblogic provides for dynamic queries as well. Does OAS allow that? But many of the features make CMP app server specific.

Would be great if you could write an article comparing Weblogic / OAS CMP features. I know quite a few weblogic tweaks but am not aware of OAS capabilities. You know am just curious, if tomorrow we decide to port our applcn to another app server, can i just tweak the descriptors and port
even though I have ended up using some specific features provided by another app server.

Isn't it like first creating a problem that shouldn't have existed in the first place and then trying to solve it.

The more and more I read about and work with entity beans, the more I realize that the so called CMP experts are a confused lot or they just used plain jdbc 1.1 with all the jdbc code sitting right in their business logic and then they found CMP where you don't need to write your inserts/updates/deletes and thought that this is the elixir.

Everything Debu mentions in this article, aren't these obvious to everyone? Do we really even bother about most of these issues when using jdbc, DAO, db handler, OR-mapping tools?
And then there are some tricks that come into existence just because of CMPs (read-only/read-mostly pattern).

I still need to see a compelling reason for using CMP instead of POJOs for persistence.

While I'm sure they're still in use (thus the turnout at your javaone presentation), this article points out some of the flaws of CMP with ejb 2.0.

We've recently went through the task of removing Entity Beans from most of our architecture, and our system performance has improved dramatically. While we tried some of the tuning suggestions you laid out (I admit not all of them), our improvments were lackluster. Our conclusion was that CMP is woefully inadequate. My advice, based on admittedly limited experience, is don't bother tuning CMP, just eliminate it.

After having a philosophical discussion with my team, I'm left with one question. Are there any compelling reasons left for Entity EJBs? I can't think of any. I know the textbook advantages of EJBs, But I can't imagine how these can't be served by Session EJBs calling POJOs. And many things can be solved without EJBs all together.

I apologize if this is not the way you wanted this thread to go, or if this is a frequent thread path in TSS (I don't read this is often as I'd like).

After the presentation, I spoke to (a) few attendees and almost every one of them use CMP entity beans in their production application servers such as Weblogic, OC4J or Websphere..."

Is there a different OC4J used in the Oracle application server ?
We used the OC4J container production release for CMR lazy-loading by turning on the 'find by primary key' switch only to see it removed by the container at runtime. We reported the bug and though it was resolved very late we decided to use DAO. We have almost given up on CMP's because the tools were inadequate and we couldn't spend a lot on other servers.

Quoting from the article:

Use DELETE CASCADE at database level
When an entity with relationships is deleted with multiplicity ONE, the container is responsible for deleting all dependent entities. The container generates and executes the required SQL code to remove all of the related child records from the database. The native cascade delete facility in the Oracle database is much faster as this avoids multiple delete statements when removing the dependent records. The database removes all related records when the CASCADE DELETE option is specified for the table.

Wonder if I should put this down as a classic case of being unable to eat one's own dogfood. My recent experience with the Oracle 10g [a wrapper tag for a newer build of version 9.0.4] container's Entity Bean implementation in this regard was not very pleasant. Oracle's container refuses to let you exploit Oracle's database's cascaded deleted using a remove() invocation when you have composite keys. The container ends up issuing an update statement that attempts to insert a NULL value into a non-nullable field participating in a composite foreign key.

George

Quoting from the article:

Use DELETE CASCADE at database levelWhen an entity with relationships is deleted with multiplicity ONE, the container is responsible for deleting all dependent entities. The container generates and executes the required SQL code to remove all of the related child records from the database. The native cascade delete facility in the Oracle database is much faster as this avoids multiple delete statements when removing the dependent records. The database removes all related records when the CASCADE DELETE option is specified for the table.

Does OC4J automatically adjust the Enity beans Involed in the relationships when the database CASCADE DELETE option is chosen so they wont have the stale instances when accessed next time?