Hi all,
        I have a question regarding Entity Bean. When i have enetity beans
representing Oracle Data and if the underlying data gets changed what
happenes
to the entity Bean's state?
        I guess the entity bean gets the changed data afetr it's ejbLoad()
call.
In that case is there any callback mechanism in Oracle to trigger this
ejbload()?

Thx,
Babu


-----Original Message-----
From: Manavendra Gupta [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 03, 2002 10:46 AM
To: [EMAIL PROTECTED]
Subject: Re: entity bean


At 08:36 AM 9/2/2002 -0600, Mohammed Javid wrote:
>Hi,
>
>please let me know on these
>
>1 Is this possible
>To have different ejb names for the same ejb and refer each ejb name with
>different jndi names and mention the parameters
>like <finders-load-bean> and other attributes of each ejb seperately based
>on different ejbname and jndi name
>Or should we deploy the same ejb with different names and then only we can
>specify different parameters to each ejb
Why would you want to have multiple JNDI names for one bean? The very
concept of JNDI relieves you from the hassles of having to locate and keep
track of components (the COM equivalent of a GUID).
Even if you strongly believe that you need to refer to the same bean with
multiple JNDI names, there can only be a one-to-one association between the
bean and the JNDI name - so, you would then need to deploy the bean with
multiple times, though it still beats me if that would benefit you in any
way.

>2 Should we use each table as a entity bean or based on what fields of the
>table are involved in the transaction we have to design entity beans  for
>same table. Which is better. Any material on this to refer.
An entity bean represents/depicts an entity in the system - be it a bank
account, a customer, order, etc. RDBMS has the concept of "Master tables" -
and you could draw a parallel and create entity beans for each Master Table.
As for what fields to include in the Entity bean, IMO, its better to have
all the fields of the underlying storage:
         1. When the underlying storage is updated, you would know exactly
what values are going in.
         2. Entity Beans will later be wrapped up by Session Beans and made
available to the bean clients. Having all fields would ensure you have all
the data with you.
         3. Entity Bean descriptors (for CMP) store the mapping for each
bean field to the underlying storage field. If you use CMP and choose to
ignore some fields, and later decide that you need them, the change
propagation is large.

>3 Can we use fields of different tables as one entity bean. Is this a ejb
>spcification or a vendor related.
How are the entities represented in your database/enterprise information
store?Do you store them across tables?
If you have master-detail relationships in your Master Tables (order-order
details, etc), you can represent them as different entity beans and manage
them using Entity bean relationships.
If you are looking to do anything else (modify certain tables based on
certain user actions, etc), you should consider using Session Beans.

HTH,
Manav.

===========================================================================
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".

Reply via email to