Hi Arkin,
I am Johann and I work on the OpenSpaces project from ExoLab,
with Jim Alateras.
I just would like to know if you could give me some interesting links
about the basics of transactions and their uses as I know you are a
very active contributor on that subject.
Many thanks,
Regards,
Johann
----- Original Message -----
From: Assaf Arkin <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 30, 1999 9:58 PM
Subject: Re: Entity Beans
> 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".
>
===========================================================================
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".
