> snip.
> 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.
>
Having the timestamp (or concurrency counter as I prefer to call it) on the
database row is the way to go, and avoids the passivaton/activation issue.
Note that counting on a single bean instance violates that a vendor
implementation may have many instantiations of the same logical PK, each in
its own transactional view.
> 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.
>
You'd have to design a hash algorithm that didn't have much chance for
collision. The more precise the hash, the more computationally costly the
execution. I don't recommend this approach.
If you want to go this route, better to save before/after images of the
state and check the collision that way. I have seen some choose to put the
before/after state check into the where clause of the update statement, thus
giving you field level concurrency control.
> 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".
===========================================================================
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".
