Both BMP and CMP can give you an entity bean from the cache instead of
reloading it (commit Option C, somewhere in the specs).
For BMP, a call to ejbLoad will always occur.
For CMP, the CMP engine may not issue a call to ejbLoad if it knows the
cached copy is current.
arkin
Peter Thomas wrote:
>
> William,
>
> For BMP, I agree that as and when each stub in the list is processed an SQL
> call will be made during ejbload to get it's state, but I thought the idea
> behind this was to get the latest data/state from the database, otherwise
> another user may have updated it (since the stub/PK enumeration was
> returned) and we would overwrite these changes ?
>
> I have notice that this reloading of state during the first access also
> accurs for CMP using Weblogic, for example I had an enumeration returned
> from a finder with 400 entity beans, and when processing the list
> sequentially, about 220 of the beans were reloaded using ejbload() . Does
> anyone know when CMP chooses to reload, maybe it is to do with caching ?
>
> Pete
>
> > -----Original Message-----
> > From: Louth, William (Exchange) [SMTP:[EMAIL PROTECTED]]
> > Sent: 14 March 2000 09:09
> > To: [EMAIL PROTECTED]
> > Subject: Re: BMP/ejbStore = all attributes required or not and why
> >
> > Hi Steve,
> >
> > Inprise Application Server already supports "tuned writes" with container
> > managed persistence (using reflection) so I do not see any problem with
> > your
> > proposal apart from a big performance hit since you are using Bean Managed
> > Persistence. Consider the findByXXXX method your bean is required to query
> > the database and retrieve a list of N primary keys (1 SQL call so far).
> > After that the container will do some vendor specific work with your list
> > and return a list of stubs to your client, lets say a session bean (with
> > tx
> > required). When your session bean accesses the state of one the bmp entity
> > beans a SQL call will be made in your ejbLoad, thus now we have (1 + n sql
> > calls). With the Inprise Application Server we can make it only inccur one
> > SQL hit by letting the container load the state in the initial sql call
> > i.e.
> > instead of select pk from sometable we have select pk, fld1, fld2.... from
> > sometable where ......
> >
> > The nice thing about container managed persistence is that you do not have
> > to write the plumbing just the logic. I have a friend who is a DBA and he
> > keeps telling me that "a good DBA is one that does nothing".
> >
> > The implications of tuned writes is better performance. Thats one of the
> > reasons why IAS is faster than most application servers.
> >
> > kind regards
> >
> > William
> >
> > > -----Original Message-----
> > > From: steve e sobczak [SMTP:[EMAIL PROTECTED]]
> > > Sent: Thursday, March 02, 2000 12:03 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: BMP/ejbStore = all attributes required or not and why
> > >
> > > 1.) This email pertains to BMP EntityBeans
> > >
> > > 2.) All the examples I have seen pertaining to ejbStore have had an SQL
> > > statement updating on the database "every" field that is persistent
> > > within that EntityBean.
> > >
> > > 3.) I have not been able to find any alternatives to this all
> > > encompassing SQL statement; no arguments as to why you shouldn't design
> > > differently.
> > >
> > > 4.) I have a pre-EJB java framework that knows how to dynamically build
> > > SQL statements based on which "specific fields" are dirty.
> > >
> > > 5.) This email is not intended to discuss the use of a whole instance
> > > dirty flag (which I've seen discussed), but specific field level dirty
> > > flags (which I have not seen discussed).
> > >
> > >
> > > So my question is this:
> > > What would the implications be if my ejbStore knew that out of all 30 of
> > > my instance attributes, only one of the attributes was dirty and it
> > > generated an SQL statement that only updated that one field on the
> > > database for this one specific invocation of ejbStore?
> > >
> > >
> > > Steven E. Sobczak
> > >
> >
> >
> > ***********************************************************************
> > Bear Stearns is not responsible for any recommendation, solicitation,
> > offer or agreement or any information about any transaction, customer
> > account or account activity contained in this communication.
> > ***********************************************************************
> >
> > ==========================================================================
> > =
> > 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
