CMP, Entity Beans and Performance implications

Discussions

EJB design: CMP, Entity Beans and Performance implications

  1. CMP, Entity Beans and Performance implications (13 messages)

    Hello,

    We're currently designing an application that will interface to an Oracle server, using Websphere 4.01.

    I'm trying to track down any documentation or information, that would help us perform some capacity planning and performance analysis on the impact of using CMP and Entity beans.

    From what we understand, entity beans under a CMP model, are populated with a single row in the database. ie: 1 entity bean per database row.

    On a small scale system, this model looks fine however, when you may have a million rows + in the database, resource management I believe would become an issue.

    We're attempting to stay away from BMP as we antipate moving to Websphere 5.x later this year, where we can take advantage of the EJB 2.0 specs including better data persistence layer integration, straight out of the box (ie: map the database to an OO model and use somethign like a Session Facade to manage the data representation more effectivly).

    If anyone has any tips, pointers or information they can share on this, it would be greatly appreciated,

    Regards

    Adam
  2. You can use Data Access Object design pattern instead of CMPs.
    thanks and best regards,
    Nanda Kumar.D
  3. Hi,

    We're using Websphere Studio Application Developer 4.01. Do you know if it allows the development of DAO's instead of CMP?

    ie: my understanding is that you can have either develop using BMP or CMP in WSAD.

    Thanks,

    Adam
  4. DAO abstracts business logic away from the persistence mechanism, it doesn't replace it. Unless I've misunderstood the point, I don't think that DAO helps you at all. You still have to persist somehow (JDBC,CMP or BMP).

    Maybe Nanda was thinking that you could abstract yourself away from say JDBC (nice and performant) using DAO and when your Websphere 5.0 comes along, you can move to EJB 2.0 CMP without changing business code.

    As I said in my other post, you can get pseudo EJB 2.0 CMP using Toplink.
  5. It's a common misconception that in CMP, 1 Entity Bean = 1 database row. EJB says nothing about this, but Application Servers' deployment mechanisms inevitably lead you to this conclusion. You can have multiple table entities using database views, as well as EJB 2.0 (as you've discovered already).

    To answer your specific question, you might consider looking at "Toplink". Yhis is an OR mapping tool from Webgain that has some quite remarkable caching capabilities. Also you can interface with it using CMP. We have proved that you can get significant performance improvements over native CMP using a tool like this.

    I do not work for Webgain, nor do I have any business relationship with them, I just like this product!

    Good luck
  6. David,

    thanks for the reply - We actually requested that Toplink was the OM of choice but the moneymen frowned at it.

    Our thoughts are that, we, with fingers crossed, keep with a well designed CMP model and, wait for EJB 2.0 and Websphere 5 (to support EJB 2.0).

    You noted in your reply "You can have multiple table entities using database views". Do you mean here that its possible to have more than one DB row per entity bean, whilst using a CMP approach ?

    Thanks,

    A+
  7. Adam

    Absolutely it's possible. I've done it myself using Websphere 3.5.1 (really old). What you need to do is get your Oracle DBA to set you up exposing your multi-table data as single views. The whole point of database views is to make multiple table data look like single table data. Talk to your DBA. Once you have the views set up correctly, your data simply looks like single rows on new tables. The view has a name, exactly the same as a table. All you need to do is map your Entity to the view, using its name, and hey presto, multiple table Entities.

    Have fun (I did)
  8. It is typically recommended that table views be used for read-only purposes. How does this influence the decision to map a CMP Entity Bean to a view?
  9. Hi David,

    View should be read only. And only read-only CMP entity beans may benifit from your proposal. What should actual tables behave when you insert a row in a view (if it's possible)? Think of the simplest situation: a view that results from a join operation over 2 tables. In one-to-one mapping, maybe creating a new row in both tables should work. In a one(table A)-to-many(table B) mapping, do you think you can define the insertion rule? And that's only insertion. What about removal and update?

    Using CMP entity beans over database views is a good idea, as long as those beans are read-only.
  10. Hi Dright,

    FYI, as we all assume the database is Oracle, you can update, insert, delete the view by writing the database trigger("INSTEAD OF") for that view. So, when ever try to update, delete, insert on that view, the database trigger code will get executed. Please check the Oracle doc for code.
  11. David,

    What about performance issues? Did you do performance analysis? I would certainly like to use your idea, had thought about it before but always shied away from it thinking of performance and also code dependencies/maintenance issues. Plus database independence – well of course that’s pushing it too far or close to perfection, whichever way you prefer.

    If someone has done performance analysis, I would be glad to see it in this thread.

    RC
  12. Sorry about that, I don't whats the deal with those 8211 and 8217. Interseting, these guys aren't using preparedStatement? Do they use EJBs - (purposely used the dash again to see if it gets replace by 8211) in that case what App Server or OR tool is doing this to them.

    What about performance issues? Did you do performance analysis? I would certainly like to use your idea, had thought about it before but always shied away from it thinking of performance and also code dependencies/maintenance issues. Plus database independence, well of course thats pushing it too far or close to perfection, whichever way you prefer.

    If someone has done performance analysis, I would be glad to see it in this thread.
  13. Hang on Adam, I've re-read your question. It definitely ISN'T possible to have multiple rows FROM THE SAME TABLE in a single entity. I can't believe that you would mean this, as each rows would have its unique primary key. You could never access a composite.
  14. David,

    Yer, you had me worried there ! I was starting to get concerned that we had all missed something major in the fundamentals of entity beans !! the way you described it, I thought there was some other method of using an entity bean with a concept called views - didn't realise you meant database views.

    Thanks !

    Adam