Chris:
If I understand correctly, then Erik is proposing to use a network of
container-managed persistence entity beans to facilitate data access, primarily
because of the ease of implementation (portability would be another reason), and
you are saying that the proposed approach will not be scalable and would
generally perform poorly. Now, I understand that the data access code generated
by the container will hardly be optimal, but I would be grateful for some more
insight into how scalability would be compromised. Let's take the following
scenario as an example:
Table/Entity: Users. Fields: Person Key (primary key, foreign key of Persons
table), User Name, Password
Table/Entity: Persons. Fields: Person Key (primary key), First Name, Last Name,
Residential Location Key (foreign key of Locations table), Mailing Location Key
(foreign key of Locations table)
Table/Entity: Locations. Fields . . .
If a session component needs to get the first and last names of a user who has
provided a first and last name, then it could cause a User entity to load, which
would cause, in turn, a Person entity to load, as well as a location entity --
clearly, all these entities lurching to life and accessing the data store is
going to slow things down and cause a traffic jam to the data store which will
adversely effect scalability. Would a satisfactory compromise solution (other
than the lazy-loading mechanism that has already been suggested in this thread)
be to have the session component get the key of person from the User entity and
then get the first and last names by doing a findbyPrimaryKey on a Person entity
-- thereby only invoking the Person entity because it needed to in that case.
This would not be as efficient as using a query that would retrieve the first
and last name of a person from the Person table given a user name and password
combination in the User table, but could still be accomplished with
container-managed persistence. I see a performance cost to the benefit of ease
and portability in that scenario but not a scalability problem. Or am I missing
something?
Regards,
Craig
Chris Raber <[EMAIL PROTECTED]> on 01/24/2000 11:18:12 AM
Please respond to A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: Entity beans referencing other entity beans
Erik said:
Yes that is very true, but... Using WLS and using CMP (which is a
very
simple member to column mapping solution) Its very fast and easy to
create.
In fact reading a DBs schema info and generating a whole CRUD
enabled
application is possible. So instead of doing BMP as you have I wan't
to use
CMP and one table is one entity.
And as I said I know the implication and that its not a very nice
component
design but I can write 20 entity beans when you have done 1.
Its as you said a question of fine- versus coarse grained design. It
is
fine grained and that's how its going to be.
Yes, but using this approach you are assured of an system that won't scale
and won't perform. It was easy to build, but how far can you go with it? I
suppose if you know at the outset that you don't have to scale, this is not
an issue.
-Chris.
===========================================================================
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".
----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and delete the material
from any computer.
===========================================================================
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".
