James Cook wrote:
> I think using a timestamp is a good idea, but it's unfortunate that we have
> to resort to modifying every table to support concurrency demands. I
> understand that this is the easiest approach. In fact, we are using the
> timestamp approach to solve our concurrency issues.
I don't like to pollute the database schema with artifacts either. Especially
when the schema changes require modifying existing "legacy" code. I use the
timestamp for only a few cases where a timestamp is desired for other reasons.
>
>
> I would object to your other idea involving the where clause, for two
> reasons:
>
> 1. The caller should be notified that the underlying data has changed by
> means of an exception since their db write will not occur.
You can catch the update failure by checking the update row count and handle the
error as you see fit.
>
>
> 2. Keeping track of the original value can be troublesome. Without the
> benefit of a persistence framework, it would probably have to be supplied by
> the client (ugh). There are other approaches that I have used in the past,
> such as keeping a hash of original values in the dependent object valuetype,
> but this is complicated when you have a graph of objects.
I agree. Keeping the original values is troublesome. Within a given physical
transaction the entity bean can keep the original and updated values. In long
logical transactions a stateful bean can hold the original data then supply it
to the entity(s) beans at the logical transaction's completion.
>
>
> A problem with timestamps is that the update may be rejected, even though
> the fields involved in the update may be modifiable anyway. This happens
> when two people try to affect a change to an employee record, where one
> changes the employee name, while the other changes his zip code. Both
> operations should be able to be done simultaneously, but the timestamp
> approach would fail. (This assumes that all columns are in the same table.)
Agreed, which is why I don't use timestamps much.
--Victor
===========================================================================
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".
