ejb performance

Werner,

We have an existing application that began with +- 50 entity beans. As the application was being built, they appeared to work well with the sample data in oracle. But...when it hit production, and volume became a factor, the entity beans, in some situations, were disastrous. They performed terribly. Since the application's first deployment, about 4-5 years ago, we've had to methodically replace many of them that were behaving as bottlenecks.

This behaviour has been observed by many, including some IBM experts who were auditing our application, who insisted that we no longer use entity beans because of their performance.

My observations:

Entity beans seem to do ok for updating the db, because most of the time there are only a few objects to save...However, extracting data has always been more complicated. If you use entity beans (especially with table mapping), it becomes long and arduous to navigate the db scheme using entity beans because often you have to create lots of them in order to get a simple list of items which have been moderately normalised in the db.

In order to benefit from the transactional aspects of EJB's we have adopted the SessionFacade (session stateless) pattern. This way we pass ValueObjects back and forth from the session facade. Stateless Session beans still suffer from the EJB framework overhead, but often the container keeps them alive so they do not have to be instanciated as often as an entity bean. With this method, however, we have to write our own SQL's...but in the case of data extranction, specific/personalized SQL's will always outgun generated SQL's.

Just some ideas,

Mark

Besides the other recommendations about architecture it is a clear YES abotu debugging slowing down your application. NEVER do performance testing in debug state.

Regards,

Benny