John Abbey <[EMAIL PROTECTED]> wrote:
> 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.
For both CMP and BMP, ejbLoad() is called each time the entity bean
gets involved in a new transaction (unless your container assumes it
owns the data (Commit Option A in sect. 9.1.10 of EJB1.1 spec.)).
ejbStore() is always called while the transaction is being committed
(it might not be called for a rollback).
> 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 err or 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.
My understanding of the EJB spec. is that there is no standard way for
the container to know if data changed, therefore it always does the
update to the database. Various app server vendors (such as WebSphere
and WebLogic) have extensions that can be used to avoid un-needed
updates.
> 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.
So long as the container is not using commit option A (I suspect that
all containers that support option A also support options B or C), the
ejbLoad() method is always triggered (once per transaction; a
transaction may span several business method calls).
> 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 to ! ! 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?
I'm not sure what you're asking here. I don't think the main goal of
entity beans is limiting database access (good databases already do a
good job of caching). The app server is allowed to reclaim any bean
instance that is not involved in a transaction.
- Bruce
===========================================================================
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".
