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
-
CMP, Entity Beans and Performance implications (13 messages)
- Posted by: Adam Neat
- Posted on: April 08 2002 22:48 EDT
Threaded Messages (13)
- CMP, Entity Beans and Performance implications by Nanda Kumar on April 09 2002 00:24 EDT
- CMP, Entity Beans and Performance implications by Adam Neat on April 09 2002 01:34 EDT
- CMP, Entity Beans and Performance implications by David Clarke on April 09 2002 03:57 EDT
- CMP, Entity Beans and Performance implications by Adam Neat on April 09 2002 01:34 EDT
- CMP, Entity Beans and Performance implications by David Clarke on April 09 2002 03:33 EDT
- CMP, Entity Beans and Performance implications by Adam Neat on April 09 2002 03:42 EDT
-
CMP, Entity Beans and Performance implications by David Clarke on April 09 2002 04:06 EDT
- CMP, Entity Beans and Performance implications by Matt Corey on April 09 2002 04:16 EDT
-
CMP, Entity Beans and Performance implications by Dright Ho on April 09 2002 11:22 EDT
-
CMP, Entity Beans and Performance implications by venkataramana janapati on April 09 2002 11:40 EDT
-
CMP, Entity Beans and Performance implications by Rohit Chaudhri on April 14 2002 11:26 EDT
- CMP, Entity Beans and Performance implications by Rohit Chaudhri on April 14 2002 11:32 EDT
-
CMP, Entity Beans and Performance implications by Rohit Chaudhri on April 14 2002 11:26 EDT
-
CMP, Entity Beans and Performance implications by venkataramana janapati on April 09 2002 11:40 EDT
-
CMP, Entity Beans and Performance implications by David Clarke on April 09 2002 04:27 EDT
- CMP, Entity Beans and Performance implications by Adam Neat on April 09 2002 04:36 EDT
-
CMP, Entity Beans and Performance implications by David Clarke on April 09 2002 04:06 EDT
- CMP, Entity Beans and Performance implications by Adam Neat on April 09 2002 03:42 EDT
-
CMP, Entity Beans and Performance implications[ Go to top ]
- Posted by: Nanda Kumar
- Posted on: April 09 2002 00:24 EDT
- in response to Adam Neat
You can use Data Access Object design pattern instead of CMPs.
thanks and best regards,
Nanda Kumar.D -
CMP, Entity Beans and Performance implications[ Go to top ]
- Posted by: Adam Neat
- Posted on: April 09 2002 01:34 EDT
- in response to Nanda Kumar
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 -
CMP, Entity Beans and Performance implications[ Go to top ]
- Posted by: David Clarke
- Posted on: April 09 2002 03:57 EDT
- in response to Adam Neat
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. -
CMP, Entity Beans and Performance implications[ Go to top ]
- Posted by: David Clarke
- Posted on: April 09 2002 03:33 EDT
- in response to Adam Neat
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 -
CMP, Entity Beans and Performance implications[ Go to top ]
- Posted by: Adam Neat
- Posted on: April 09 2002 03:42 EDT
- in response to David Clarke
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+ -
CMP, Entity Beans and Performance implications[ Go to top ]
- Posted by: David Clarke
- Posted on: April 09 2002 04:06 EDT
- in response to Adam Neat
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) -
CMP, Entity Beans and Performance implications[ Go to top ]
- Posted by: Matt Corey
- Posted on: April 09 2002 16:16 EDT
- in response to David Clarke
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? -
CMP, Entity Beans and Performance implications[ Go to top ]
- Posted by: Dright Ho
- Posted on: April 09 2002 23:22 EDT
- in response to David Clarke
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. -
CMP, Entity Beans and Performance implications[ Go to top ]
- Posted by: venkataramana janapati
- Posted on: April 09 2002 23:40 EDT
- in response to Dright Ho
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. -
CMP, Entity Beans and Performance implications[ Go to top ]
- Posted by: Rohit Chaudhri
- Posted on: April 14 2002 11:26 EDT
- in response to venkataramana janapati
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 -
CMP, Entity Beans and Performance implications[ Go to top ]
- Posted by: Rohit Chaudhri
- Posted on: April 14 2002 11:32 EDT
- in response to Rohit Chaudhri
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.
-
CMP, Entity Beans and Performance implications[ Go to top ]
- Posted by: David Clarke
- Posted on: April 09 2002 04:27 EDT
- in response to Adam Neat
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. -
CMP, Entity Beans and Performance implications[ Go to top ]
- Posted by: Adam Neat
- Posted on: April 09 2002 04:36 EDT
- in response to David Clarke
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