Hallo se,
this is not explicitely stated in the spec, but I tested it with the j2ee-ri and
it works fine: Bean type A and bean type B can all define each an env-entry with
the same name (i.e. "helper") and these entries will not overide each other.
Se Hee Lee wrote:
> In EJB 1.1 spec, it seems that environment variables are shared by instances
> with same home, but not shared by other beans.... Does this mean that bean
> provider can create the environment variable with same name for every ejbs?
> For example, Can I have three different entity beans with same env-name, but
> their values are different?? and, can I expect that each bean instance grab
> only the environment variables that are avaible to it? Any help is
> appreciated.
>
> Se Hee
>
> -->-----Original Message-----
> -->From: A mailing list for Enterprise JavaBeans development
> -->[mailto:[EMAIL PROTECTED]]On Behalf Of Al Fogleson
> -->Sent: Tuesday, May 16, 2000 11:38 AM
> -->To: [EMAIL PROTECTED]
> -->Subject: Re: Object-relational problem
> -->
> -->
> -->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".
> -->
> -->
>
> ===========================================================================
> 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".
--
Francis Pouatcha
MATHEMA Software GmbH
http://www.mathema.de
===========================================================================
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".
