Ben Strulo wrote:
> > Doesn't the above code look much better? Of course we had to build an
> > entire
> > infrastructure of smart keys which implement the remote interface,
> > maintain
> > their own identity (primary key), lookup the proper stateless session, and
> > delegate requests to the stateless session bean. Hmmm .... this all looks
> > very
> > familiar. Don't entity beans accomplish basically the same thing? They
> > maintain an assocation between a remote reference used by the client and a
> > primary key. Of course they do it automatically on the sever and hide the
> > details from the developer. If we had just used entity beans in the first
> > place, we would have obtained exactly the same benefits with at least the
> > same
> > performance if not better.
> >
> However, it is not clear to me that these two solutions [smartkeys vs entity
> beans] are really comparable from a performance point of view. In the smart
> key case the references are held on the client. Thus the storage demand on
> the server is constant as the number of clients increases. In the entity
> bean case the server is maintaining some kind of entity-bean instance table
> (mapping references) and this will use storage linear in the number of
> concurrent clients and hence damage scalability (certainly in extreme
> cases). Essentially, in the smartkey case, there need not be any bottle-neck
> on the server until you get to the database whereas, in the entity bean
> case, there also has to be this lookup as a bottle-neck.
>
> Under what circumstances can the entity bean model outperform the smartkeys?
> The scope for optimisations within the server seems to be quite restricted
> by the EJB semantics. (However I'm probably missing some obvious point...)
The example is intended to illustrate the point that entity beans provide
implicit identity. This allows you to avoid programming something as stupid as
the "smart keys" yourself. Why program smart keys when you have entity beans?
I hope no body reads this and thinks, "Smart keys, what a great idea!" If that
happens then my point was totally lost.
Regarding performance: Maintaining primary keys doesn't place much of strain on
the server. The benefits of having implicit identities associated with entity
beans far out weigh any minor performance penalties. I think you would be hard
pressed to demonstrate that "smart keys" out perform entity beans in load
testing -- even with huge loads -- unless you're using a poorly implemented EJB
container.
Richard
--
Richard Monson-Haefel
Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.EjbNow.com
===========================================================================
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".
