I've been developing EJB based components for some time now and wanted to get some
basic information on how entity beans really behave. I've read several articles and
reviews of how they work and how they are supposed to work. Needless to say, I've
seen quite a few indications that the current state of the technology has left me
concerned with how "in memory databases" and entity beans will work in a real world
(i.e. not a student's end-of-term project) application environment.
If anyone could answer the following questions, I'd greatly appreciate it. Since some
of the questions I'll be asking will have varying answers (depending on the EJB
Container Vendor), feel free to focus your answers to a given EJB Vendor (i.e., BEA
WebLogic, IBM, etc).
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.
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.
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.
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?
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".
