> 1. Using CMP, does ejbLoad() get triggered every time you do a "find" on the
>entity? I know that the container shouldn't do this, but I've read articles that
>indicate that just to make sure the data in the entity bean (in memory) has the
>correct data, it executes ejbLoad() every time.
In BMP, ejbLoad and ejbStore are used to load and store the entity bean
to/from the database.
In CMP, the EJB server loads and stores the directly and only calls
ejbLoad/ejbStore to allow the bean to modify fields prior to storage or
after retrieval. For example, the bean might need to do a text.trim() on
a value loaded from a CHAR(n) field.
So, after the bean is loaded in CMP (either finder or create), a call to
ejbLoad is mandatory. But unless you wrote any code in ejbLoad, nothing
will happen, so there's no overhead. The same applies to calling
ejbStore prior to storing the bean.
> 2. Using CMP, how does the entity bean know when to trigger the ejbStore() method?
>Does the entity get marked as "modified" if I perform a setxxx() on one of the
>object's properties? If that's the case, if I perform a setxxx() on only one
>property, does the container execute ejbStore() and update all the DB fields for that
>bean, even though I only changed one field? If that's the case, I'm performing
>updates on fields that really haven't changed. Depending on the DB vendor, this
>could result in an error right? In addition, it seems wasteful to perform an update
>on 30 fields when I only changed one, especially if the DB fields have constraints
>applied to them.
The CMP will not track change to a single field and immediately store
the bean. Typically it will wait until the end of the transaction to
store the last state of the bean. As to how many fields are actually
changed, that's up to the CMP implementation, and actual overhead is
more dependent on the database.
> 3. What if other systems (i.e. batch processes that run outside of the EJB
>application) update application data? Does that mean my data in my "in memory"
>entity beans will essentially be stale? I would think so, unless the ejbLoad()
>method is always triggered and therefore the DB is always hit.
Yes.
There are three solutions around this problem:
1. Dirty check before storing the bean which tells if the database has
changed since the bean has been loaded into memory.
2. Always load the bean before using it and lock the relevant database
rows.
3. Cross your fingers and hope for the best.
This is not clearly defined in the current specs and is pretty much up
to the EJB server you're using.
> 4. I believe the general reason to use entity beans is to limit making calls to the
>DB and to have the application server determine when/if I make calls to the DB. In
>addition, the use of "in memory" databases should limit DBIO traffic significantly.
>However, the use of "in memory" databases seems as though it could drastically impact
>the resources being consumed on the EJB Application server. For example, if I have
>150,000 different users login to my EJB Application and my user information for each
>user is contained within an entity bean, I have 150,000 entity beans (The userBean
>object) in memory simply at the point of login. Yes it's wonderful that if I need
>userBean data I can simply to a find() and in theory I won't even have to retrieve
>the info from the database. But what if I don't need it anymore? Seems like a waste
>to keep it around if I only use the object at login. In addition, if the vendor has
>decided that the ejbLoad() method is going to be triggered t!
!
!
o !
> ensure that data is up-to-date, I hit the DB again? Now I've made the additional DB
>hit and I also consumed resources on the EJB Application server?
Unless you use the bean it will simply passivate itself and remove
itself from memory after a period of time.
But you're right to observe that entity beans have many limitations and
shouldn't be used just because they are more convenient. In this
particular case it will be more efficient to have a stateless session
bean do a simple SELECT against the database. In most cases, doing an
UPDATE from a stateless session bean is significantly faster than using
an entity bean.
Entity beans really come into play when your objects are complex to
begin with and so are the interactions with them, or when you need the
abstraction from the database schema (i.e. you can map the same set of
beans to different databases).
arkin
>
> Thanks so much for any insight on this.
>
> John Abbey, AMS eCustomer
>
> ===========================================================================
> 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".
