Bruce Adams wrote:
> 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).
Regarding CMP, it is up to the container to decide whether to
synchronize the entity bean when it is invoked in a new transaction,
based on the commit option. If it choose to synchronize with the
database, it must call ejbLoad. If it choose not to synchronize, it must
not call ejbLoad, since ejbLoad assumes (for CMP only) that new contents
has been loaded.
For example, ejbLoad might convert metric measurement from the database
into non-metric in memory, each time the entity bean is sycnrhonized,
and ejbStore will do the reverse. They must only be called if
synchronizatio occurs, and immediately prior (ejbStore) or after
(ejbLoad) it completes.
> 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.
Most logically at the end of the transaction in which the entity bean
was involved while the method was invoked.
The CMP engine can compare the entity bean with a cached copy to
determine if there are any changes that warrant 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).
Even that is not very helpful, unless you use pessimistic locking.
Unless the object is locked, it could be changed while the entity bean
is executing.
The two solutions are explicit locking (i.e. lock object when starting
entity bean method) and dirty checks (i.e. check database copy against
cached copy to determine external modification). A good CMP engine
should support both.
arkin
>
> > 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".
===========================================================================
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".
