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 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.
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.
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.)
jim
----- Original Message -----
From: Victor Langelo <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 12, 2000 1:37 PM
Subject: Re: Serialized Access
> James,
>
> It isn't really all that hard to insure that nothing has changed. As
mentioned
> by Stefan Tilkov, you can use time stamps or version numbers. Another
option
> that gives finer grain control is to save a copy of the original data then
> construct an update statement like the following:
>
> UPDATE EntityTable SET column1 = newValue
> WHERE primaryKey = key AND column1 = originalValue;
>
> Obviously this is also a simple example. So I know that there are problems
when
> the column count is high. Using a persistence layer that constructs the
SQL for
> you means that you only have to deal with the concurrency exceptions when
they
> arise.
>
> --Victor Langelo
>
>
> James Cook wrote:
>
> > ----- Original Message -----
> >
> > As a simplified example (pseudocode):
> >
> > Stateless Session Bean
> > =======================
> > public void incrementValue(int pk) {
> > entityBeanRemote = entityBeanHome.findByPrimaryKey(pk);
> > int value = entityBeanRemote.getValue();
> > value++;
> > entityBeanRemote.setValue(value);
> > }
> >
> > (Before anyone suggests that you could move the increment into the
entity
> > bean, or perform the JDBC in a single transaction in the session
> > bean...don't. This is a simple example, and illustrates the fact that an
> > entity bean and its dependent objects are most commonly accessed using
bulk
> > accessors as this example shows.)
> >
> > With IAS, and other optomistic concurrency models, you have to ensure in
the
> > ejbStore() that the originally read value did not change before the db
write
> > takes place. This involves some serious thought on how to ensure this
fact,
> > and db isolation will not save you.
> >
> > jim
> >
>
>
===========================================================================
> 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".
