No, my comment is related to the targeted marketing that Inprise is doing
on this mailing list. People new to the list may not realize that you
work for them. You certainly do not put it on your signature or advertise
it in your messages.
I have no quarrel with IAS, but I for one would rather hear a somewhat less
biased opinion on it's merits. If IAS is so great, let your customers laud
it.
Other vendors posting to the list use the <vendor> </vendor> convention at
minimum
to identify that their opinions may include good points, but are in essence
somewhat of a plug.
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Louth, William (Exchange)
Sent: Tuesday, April 04, 2000 11:32 AM
To: [EMAIL PROTECTED]
Subject: Re: Implementing using CMP quickly runs in to limitation...
David,
I was asked "what is ur view about this issue." I did make a qualification
at the start of my email. Which you could have used to as a signal to stop
listening; if you care not for facts. I have no problem with some people not
listening. I do have a problem with people trying to stop others from
telling and knowing whats out there.
Many projects are failing at the moment due to bad choice in ejb servers;
there are many other reasons but this one is very relevant here. If with my
posts I can stop this through either getting others vendors to deliver the
same features, the features becoming standardized, or ensuring that these
ejb servers do not get the chance, then so be it. How many previous posts on
this board mention either Web Logic of Web Sphere. I am currently looking at
3 that just arrived and all have vendor specific problems. I am not talking
about problems I am talking about solutions which vendors are free to go off
and implement. There is no mention of secert caching technology or whatever,
just good container design. You should also consider that users are not the
only people on this board. All vendors have dedicated people watching this
board. These people are quite intelligent and can see potentially new
features for their application server.
There is now way I could have addressed the question of cmp entity beans
versus bmp entity beans without mentioning the features that where used. If
I had not mention the server the next post would have been "What server are
you using". David, you comment was short and cheap. I welcome you to come
back and discuss the features I mentioned. Does your choosen server support
them? Do you think they really make a big difference? Does your server have
other nice and wonderful features that you have used along with your design
abilities? I would like to see more posts on the different servers and how
they compete with others. To me the biggest decision can be the choice of
server. How many times have we seen people posts messages asking which is
better, which servers support this and that. I think we would all benefit if
all vendors threw their hats into the ring. Maybe my choice is not the best;
I will quickly find out. As I stated before the tools we use, most of the
time dictate our style and choice of design. I want to use better tools that
make me design and deliver better than my natural talent. I want to know
what is the best and what we make me the best. I am a technologist and not
some manager who decisions can be driven by some cheap lunch date and croc
smiles. Your post reminds me of that scene from A Few Good Men where Jack
tells Tom "You can't handle the truth". I would consider myself a "Tom
Cruise" guy who would like the truth, so tell me different and stop this.
One more thing. I have over the last few weeks downloaded more than 5
different EJB servers. Is this the action of a "convert". x
tut, tut, tut....
William Louth
PS: I will not reply to any more posts on this subject unless there is some
real content in them.
> -----Original Message-----
> From: David Regan [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, April 04, 2000 6:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Implementing using CMP quickly runs in to limitation...
>
> covert vendor detector going off.
>
> -David
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Louth, William (Exchange)
> Sent: Tuesday, April 04, 2000 8:15 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Implementing using CMP quickly runs in to limitation...
>
>
> 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".
>
> ==========================================================================
> =
> 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".
