RE: Locking records in DB2

> From: Paul Holm
> 
> The question for debate is why use timestamp or counter fields when
one
> can use the actual database fields.

And the answer is: because checking one counter field can do the work of
checking dozens of database fields.  Simple, and far fewer cycles,
especially if you're talking about comparing strings.


> 3.    When you want to update the database, a generic method runs so
that
> loops through each Field beans and asks if it has changed.  If all
Fields
> return false, no update occurs, if they have changed, SQL is generated
> where
> ONLY the fields that have changed are on the UPDATE .. SET Field1 =
> 'NewValue'  and key fields plus any non concurrent fields are
generated in
> the "where" clause.

This is a whole lot of unnecessary cycles.  It will, of course, handle
the case where you don't know whether or not you should update the
record.  Then again, so would a simple record-level (or more precisely,
field-group level) Boolean flag.
 

> The benefit of this is generic code in a single location handles ALL
> updates to all files as well as concurrency checks.  Once written the
> code is used for all cases present and future versus custom code for
> each file and application.

I don't understand the reasoning here.  The counter check could be just
as generic.  In fact, in many cases it could be even easier because you
could use a common name for the check.


>public boolean isChanged() {
>// we use the fieldNames.size() for performance reasons
>Field field = null;
>for (int i = 0; i < getFieldNames().size(); i++) {
>  field = getField(i);
>    if (field.isChanged() &&
>      !(field instanceof ICurrentValueField)) {
>      return true;
>    }
>  }
>  return false;
>}

All fine and dandy, but it requires two things: a whole lot of metadata
and a whole lot of cycles.  Here's the counter version:

public boolean isChanged()
{
  return (counter != saveCounter);
}

It works very well in RPG as well:

P isChanged       b
D                 pi          N
 /free
  return counter <> saveCounter;
 /end-free
P                 e

This will outperform the field by field check.


You talk about custom code for each file.  In my case, the customization
is in the code that determines whether the counter needs to be
incremented, which is indeed specific to each record format.  But you
have the same information in your system, you just don't show it.
Somewhere you need a dictionary of meta-data that defines each field in
the file.  It may even be hardcoded class definitions.  For example,
every "important" field must implement ICurrentValueField.  You don't
show where all that is done.

The counter technique doesn't need that level of information; it just
checks the counter field.

Not only that, but the technique you describe doesn't handle the
situation where there are multiple sets of mutually updatable data in a
single record.  Let's say address information is one set of data that
must be updated in total, while credit information can be updated
independently.  With the counter technique, you'd specify two counters,
one for each set of fields.  That way, two people could independently
but simultaneously update the two sets of data, and you wouldn't get a
collision.  That won't work in your scenario.


I'm not saying your code is bad Paul, I'm just saying it's not
necessarily the best solution for all cases.
 

Joe