David,
I work for Bear Stearns which can be seen in the footnotes of my posts. I
would like in the future to work with Inprise but the problem is that I am
probably not good enough and I am based in Dublin, Ireland. Bear Stearns
does not currently use IAS. My last employer a very large American
telecommunication company begining with A did. Where I built a great voice
network management console. I am currently working with a team of guys who
think their current app server STINKS; I will protect the vendors identity.
These guys had no choice, others might be not so unfortunate.
You say:
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.
Which basically translate into "Build it and they will come". The only
problem with this is that most customers are not ghosts so they do not have
knowledge of everthing thats going on in the world never mind some small
little field. Inprise is addressing this issue outside of this newsgroup; I
hope. I have not seen anything that justifies your claims. I think there has
been many more plugs by other vendors. I do not have a problem with this as
long as they stick to the facts. In fact I like it since I get to know more
ejb products and all from one source.
David, stick to the facts. I have not made any wildly extravagant claims
that cannot be supported. If I have please show me and I will retract or
modify those statements. I maybe a bit LOUD, which could be attributed to
the pronunciation of my surname, but hopefully interesting. As they say in
the UK "Its Good To Talk".
<user-of-ias>
William Louth
<user-of-ias>
> -----Original Message-----
> From: David Regan [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, April 04, 2000 8:35 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Implementing using CMP quickly runs in to limitation...
>
> 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".
***********************************************************************
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".
