Rickard said:
> If you're talking about clients doing lots
> of set* calls instead of setData-type calls, sure, the overhead is more
> or less linear with the nr of calls, so you'd want to minimize those.
> One of the best way to do this is to use this technique (=use
> data-objects):
> http://www.javaworld.com/javaworld/jw-11-1999/jw-11-ejb.html
<http://www.javaworld.com/javaworld/jw-11-1999/jw-11-ejb.html>
This article, besides discussing the setData benefits, recommends
timestamping the beanProperties object, so that when the object is returned
to the entity bean, the bean can determine if a race condition is in effect
(timestamp doesn't match).
I see a big problem with this. Even if only a single client were accessing
and subsequently updating the properties, the entity bean may have been
passivated in the interim. This would cause the bean's timestamp to be
recreated on activation, which would throw a "RaceException" to the client;
or, the timestamp would need to be serialized in the ejbPassivate() method
and retrieved during activation; or, the timestamp would need to exist in
every database row.
Anybody have any comments on whether an entitybean superclass containing a
hashcode (checksum) algorithm implemented via reflection would be a better
approach? Then the hashcode would (if properly implemented) always return
the same value for the same data, regardless of passivation etc.
John Finlay, Enterprise Architect
Applied Technology Research (ATR) Group
EDS Systemhouse, Inc.
ATR web: http://atr.esolutions.eds.com
===========================================================================
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".
