Tim-
There was a really good post a while back from Charlie Alfred on what
heuristics to use in deciding what to make an entity bean and what to make a
"dependent object" - see
http://archives.java.sun.com/cgi-bin/wa?A2=ind0003&L=ejb-interest&P=R41286.
If scalable performance is a concern ("now the page is hit a lot"), you
might want to minimize entity bean usage for several reasons: i) entity
beans are heavyweight remotable objects that, in a high-scale scenario,
could saturate your server VMs and/or cause your EJB container to spend a
lot of cycles activating/passivating them; ii) unless you can run your
entity beans in your servlet engine VM (in which case why have them) you'll
be making a lot of remote invocations to getCustomerName(),
getAddressStreet(), getAddressCity(), etc; iii) maybe your EJB container
vendor provides non-standard optimizations to alleviate i) and ii), but then
you're container-dependent, so what is EJB buying you? You end up trading
scalable performance against buzzword compliance and standards compliance.
In any case, the other part of the problem is the O/R mapping part, which
contributes to the response-time aspect of performance, as you note. You
could escape that whole contribution by storing (or caching) the (O/R
mapped) instances of your domain abstractions directly in an OODBMS, like
GemStone.
Best Regards,
Randy Stafford
Senior Architect
GemStone Professional Services
> -----Original Message-----
> From: Tim Fox [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, May 18, 2000 10:18 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Object-relational problem
>
> Umm..
> It seems you're suggesting doing a table join in code.
> I've always thought this practice somewhat dangerous - you're essentially
> competng with programs like Oracle which specialise in doing this.
> May work for a simple join on two tables, but what about 3 or 4 ?
>
> Al Fogleson wrote:
>
> > Nothing says that the address has to be an EJB. :)
> >
> > You could make the address a class and have it grab all the addresses
> from
> > the database, then in the customer bean you can match the address with
> the
> > customer using the PK and FK relationship. if you further implement the
> > address class as a singleton it can retain the result set over multiple
> > instances of the Entity bean. In your case I would likely use a
> > findAllCustomers, and spit that back to the rendering engine to put on
> the
> > web page. makes for 2 database calls, one to get all the customers, and
> one
> > to fill the address class.
> >
> > Al
> >
> > ----- Original Message -----
> > From: Tim Fox <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, May 18, 2000 11:17 AM
> > Subject: Object-relational problem
> >
> > Here's a problem I've been chewing over for a while now and haven't come
> > up with a satisfactory solution.
> > It's one of the classic object-relational problems.
> >
> > Here's a simplified description (please note that this is a fictitious
> > example - I've simplified it for clarity)
> >
> > I have 2 ejbs: a Customer and an Address.
> > The customer has a home address.
> >
> > I'm displaying a list of all customers satisfying certain criteria along
> > with their home address on a web-page.
> >
> > There would be one customer & address per line.
> >
> > This would look something like:
> >
> > Customer Name Customer Address
> > =========== =============
> > Joe Bloggs 1 High Street, Newtown
> > John Doe 23 Synchronicity drive, London
> > Jane Doe 2 Big Street, Badville
> >
> > Now the page is hit a lot so I want to get the entire list using one
> > query - this is pretty easy in SQL - a simple join across the customer
> > and address tables.
> >
> > The last thing I want to do is query for all the customers, then, for
> > each customer query for the address - this would cripple the system
> > since I'd have a new query for each row of the page.
> >
> > However, if I'm using ejb then it seems I could either:
> > 1.
> > Use a finder method to get the list of customers given the criteria,
> > then...
> > For each customer in the list, use the findByPrimaryKey() (or whatever)
> > method to find the address.
> > This is probably the worst solution since it would probably involve a db
> > query for each customer address.
> >
> > 2.
> > Use a finder method to get the list of customers given the criteria,
> > then...
> > Use a finder method to get the list of addresses given the criteria.
> > This basically involves running the same (or very similar) query twice -
> > once in the Customer finder method, and once in the Address finder
> > method.
> > This, although better than 1) seems very wasteful
> >
> > 3.
> > Do the query once, and pass the resultset into the finder methods of the
> > customer and address objects - don't know if this is possible though due
> > to remote calls and marshalling of the resultset
> >
> > 4. Create a denormalised ejb called AddressCustomer which is an
> > amalgamation of the Address and Customer objects. Yuck!!!
> > Then I also end up with an AccountCustomer, AccountCustomerStatement,
> > ProductManufacturerSupplier etc. ad infinitum objects.
> > Basically the nice OO model gets shot to f*** !!
> >
> > I'd been interested in any comments/solutions people have implemented,
> > as this is really bugging me
> >
> > (BTW if I wasn't using ejb I'd use 3) since I wouldn't have any remote
> > calls problems).
> >
> > Cheers
> >
> > --
> > Tim Fox (��o)
> >
> > Senior developer
> > Hyperlink plc
> > http://hyperlink.com
> >
> > email: [EMAIL PROTECTED]
> > phone: +44 (0) 207 240 8121
> >
> >
> ==========================================================================
> =
> > 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".
>
> --
> Tim Fox (��o)
>
> Senior developer
> Hyperlink plc
> http://hyperlink.com
>
> email: [EMAIL PROTECTED]
> phone: +44 (0) 207 240 8121
>
> ==========================================================================
> =
> 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".
