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".
