Hi Anamitra,
I am only going to talk about my experience with IAS 4.0. Other servers
might have some of the features I mention. They might even have more. I
expect you will find this out after this post. I will let each products
users report their own experience. The IAS team have geared their product to
reducing any performance overhead associated with CMP. They believe in some
cases that they might be even faster that session beans using jdbc. Some of
the nice features included are:
1. Tuned Writes/Automatic read-only access detection
Basically the server uses Java reflection to inspect you entity beans when
they are accessed within a transaction and only generates sql update
statements when they have been updated. Some other containers use other
means for telling has something changed. Some rely on you to write code to
flag the change. Others use flags on the method call indicating the access
is read only. IMHO opinion the true test is the inspection of the bean using
reflection; it just cannot go wrong with this unlike the other options.
There are some issues with this when the fields are complex but by and large
this will not be such a big an issue. The inspection places the
responsibility on the container instead of the developer; sounds good to me
what do you think? Another benefit with the server is that when the server
has to perform an sql update call it dynamically generates the SQL prepared
statement for updating only those fields that have changed. Some servers
generate the SQL code when you run them through their "ejb
compiler/deployer", thus they must make an sql update call for all fields.
Question: Has anybody got any figures on what the performance hit there is
with this over tuned write?
2. Loading/Caching State
You can flag the finder method in the server to load the state of the beans.
This results in one SQl select call i.e. select pk, field1, field2,....from
sometable where field1=?. Note the benefit is only achieved for access in
the current transaction. Subsequent calls to the beans outside of the
transaction will involve another sql select statement. So do all of your
work in the transaction. My server also allows for a flag to be set on a per
entity bean basis which informs the container that the state loaded can be
used across finder calls and bean access. I believe some other servers
support this feature too.
3. Caching Prepared Statements
see post "Re: 'local' entity beans vs dependent objects" by Jonathan K.
Weedon [[EMAIL PROTECTED]].
I believe that in most business systems that these features will out perform
any handcrafted jdbc stuff you can come up with. In the systems I have
architected we have achieved better performance over the alternatives. Best
of all you will probably cut your bug rate and have more time for the
important things. There is still so many others design problems to solve
without having to do this.
If you server does not have these features you should consider using the O/R
mapping plugin or getting a better server.
kind regards,
William Louth
Note: I am talking about operational systems and not some nice reporting
front end; its hard to get one rule to fit all situations. What you should
try to do is think about each design issue carefully considering what
different solutions are presented to you by your server and try to
effectively trade off all of those wonderful software metrics against each
other. Then when you have done some analysis, prototype it. Its better to
get burned early on than later; the scars will heal by the end of the
project.
> -----Original Message-----
> From: Bhattacharyya, Ana [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, April 04, 2000 2:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Implementing using CMP quickly runs in to limitation...
>
> Hi William
> I am a bit curious about the point 3a. Well I always thought that the way
> BMPs work in case of finders is pretty stupid making n+1 queries instead
> of
> 1 queries. But are u sure that in case of CMP this is 1 query!!! Is it for
> all the servers or for some specific server/vendor. Does ejb spec say
> anything 'bout that? Also what do u think about the performance of CMP
> compared to BMP? - I mean which one is better performant. I have heard lot
> of views like this that --- in BMPs u can do fine tuning of the queries
> which is not possible in case of CMP -- hence BMPs are better performant
> that CMPs. what is ur view about this issue.
> TIA
> Anamitra
>
> -----Original Message-----
> From: Louth, William (Exchange) [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 04, 2000 6:26 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Implementing using CMP quickly runs in to limitation...
>
>
> You have the following options depending on exactly what you join
> statement
> is doing.
>
> 1. Get a good cmp engine. The obvious. One which supports calling stored
> procedures from the finder would be useful in the meantime until better
> mapping tools are provided. TopLink could be an option; I am not an expert
> user but I have heard good things about this add-on product.
>
> 2. Embed a sub-select query in your finder's where clause. This can be
> used
> where you do know have access to the complete sql statement i.e. the FROM
> section.
>
> 3. Create a hybrid entity bean which uses container managed persistence
> for
> all others finders, ejb* apart from the join finder. The hybrid can then
> do
> the one of the following:
>
> a. Issue the complete SQL statement to the database. The problems with
> this
> are performance and maintainability. The performance of the affectively
> bean
> managed find method is that number of SQL statements can be quite high. If
> you find method returns 1000 primary keys this will result in 1 + 1000 SQL
> statements for the loading part. Container managed persistence can be
> configured to reduce this to 1. The find method returns all the state
> instead of just the primary key.
>
> b. Call another find method on the same home (same bean impl) with some of
> the parameters and then with these beans perform some query on the
> association i.e. issues selects against the second home (if the table maps
> to an entity bean) using the primary key of the first bean. This work in
> the
> case ofa 1-M relationship. The benefits here is that we can potential
> reduce
> the number of SQL calls since the first home will load the state from a
> super set of our result set.
>
> c. Start from the other entity bean or table and work back.
>
> There is probably more ways of combining these things. The performance of
> your system will be indicative of the number of SQL calls you make. So
> analyse the data / key distribution and see when you can reduce it by
> using
> the some of the above.
>
> kind regards,
>
> William Louth
>
> > -----Original Message-----
> > From: Alex Paransky [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, April 04, 2000 4:23 AM
> > To: [EMAIL PROTECTED]
> > Subject: Implementing using CMP quickly runs in to limitation...
> >
> > I started to implement my system using CMP Entity Beans. However, the
> > minute I needed to execute a JOIN in order to implement one of the
> finder
> > methods, I realized that I have a problem. It seems, that CMP is only
> > good
> > for TRIVIAL object relationships. The minute a query needs to JOIN from
> > more than one table in order to execute the find, CMP shows it's
> > limitations. This means, that for all but the simplest of objects, I
> need
> > to use BMP (which appears to be much slower). Is this what most of you
> > have
> > found? Am I missing something when it comes to CMP?
> >
> > Thanks.
> > -AP_
> >
> >
> ==========================================================================
> > =
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
>
> ***********************************************************************
> Bear Stearns is not responsible for any recommendation, solicitation,
> offer or agreement or any information about any transaction, customer
> account or account activity contained in this communication.
> ***********************************************************************
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
