The problem in general is the EntityBeans have a rather heavy footprint
(Home/Remote/Impl, pass by value semantics, activation, deactivation,
finders...). Using them to represent fine grained objects will cause a drag
on system performance.
There is a lot on Entity Bean granularity in the achives.
-Chris.
> -----Original Message-----
> From: Craig McMurtry [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, January 24, 2000 2:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Entity beans referencing other entity beans
>
> 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".
===========================================================================
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".
