Hi Cedric,
In the case of complex fields I would agree; for the sake of performance. In
the case of simple fields I disagree on the grounds that the cmp engine can
never be wrong since it looks at reality i.e. the state that will be saved.
Where as we are humans and the code will never be stagnate; I think you can
agree on this. I will trade a very, very small if not negligible performance
hit for the sake of future correctness in my software. But please consider
the fact that the current vogue for large grain beans could be based on the
immaturity of the entity bean technology and container managed persistence
engines.
The isModified solution does work pretty good when the code is correct and
there is only readonly access. How does it fare when only one field has
change in an entity bean whic has say 20 fields? Can somebody shed more
light on this performance issue? is it significant.
you mention:
- use serialization, then switch progressively to externalization
Are many people serializing complex object fields to relational databases
i.e. mapping it to a field? I would some feedback on this area and what
pitfalls to watch out for. I have used some compression techniques but not
this.
you mention:
- use CMP, then switch progressively to BMP for a more optimized use of the
datastore
When does bmp outperform cmp especially considering the current contract
with the container? Are you refering to the use of some other o/r mapping
tool.
kind regards,
William Louth
> -----Original Message-----
> From: Cedric Beust [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, April 04, 2000 7:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Implementing using CMP quickly runs in to limitation...
>
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Louth, William (Exchange)
>
> > Basically the server uses Java reflection to inspect you entity beans
> when
> > they are accessed within a transaction and only generates sql update
> > statements when they have been updated. Some other containers use other
> > means for telling has something changed. Some rely on you to write code
> to
> > flag the change. Others use flags on the method call indicating the
> access
> > is read only.
>
> I would tend to conclude : the best containers offer you both.
>
> It is indeed useful to be able to rely on the container to detect changea
> and
> generate a SQL update only when needed, but the introspection code can
> only be
> so smart. Nobody knows better than the programmer when a meaningful change
> has
> been made, thus the importance of having the option to write a
> isModified()
> method.
>
> This is just an illustration of a more general methodology, particularly
> well
> adapted to Java :
>
> - rely on introspection performed by the container to prototype your
> application and focus on its business logic
> - replace introspection with hand-coded parts as you switch into
> production
> mode
>
> Some examples would be :
>
> - use serialization, then switch progressively to externalization
> - let the container checksum the bean to detect a change, then hand-code
> isModified() methods where you know you can outsmart it
> - use CMP, then switch progressively to BMP for a more optimized use of
> the
> datastore
>
>
> --
> Cedric
>
> ==========================================================================
> =
> 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".
***********************************************************************
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".
