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