RE: framework question

> From: CWilt@xxxxxxxxxxxx
> 
> Joe, it's pretty simply really.  You've got an application that
updates
> multiple records in multiple files.
> What happens if for whatever reason you can't update a particular
record
> you
> need to.  Perhaps the record has been locked by someone else, or
deleted,
> located on a IASP that just went offline, or whatever.  You can't just
> ignore this, as you'd be leaving the DB in an inconsistent state with
the
> transaction you were working on partially completed.

Ah, this is indeed a good example, Charles.  It's probably the ONLY
reason for using commitment control - as a multiple-record lock.  But
let's take a closer look at your examples:

For instance, you don't REALLY want to commit transactions over multiple
machines, do you?  That means that if one machine goes down for any
reason, the other machine can't process.  This seems to defeat the
purpose.

Or how about committing across storage pools that go offline?  Same bad
decision.  These should be queued asynchronous updates, and thus cannot
be committed.

Okay, how about the record deletion issue?  What if someone deletes the
record I was going to update?  Well, that means I blew an application
lock somewhere.  This is the crux of my argument, in fact.  Any set of
related records that need to be updated ought to have a single record
that is at their root.  Now this may not always be the case; let's leave
that case, shall we?

So, we agree that for this discussion, you can lock that single record.
And now, there is no reasonable way someone can update records in the
set unless they go outside the boundaries of my application.  You say
"but what about ODBC access"?  And now you know why I hate ODBC, or any
other sort of unmanaged access to the database.  By enforcing proper
application design (which to me involves wrapping database files in
servers) then there's no need for commitment control to prevent
destructive co-access.

So that leaves those situations where you don't have a record to lock.
Well, when you think about it, what exactly are those situations?  Mass
price updates?  File reorgs?  In most of the cases I can think of, the
lock at this point should be on the file itself.

So, once again I fail to find an absolute necessity for commitment
control.  Granted the multiple record lock looks at first glance like it
requires some form of CC, but upon further review it seems that
commitment control is really more of a false sense of security than
anything.

Especially given the cost.  We've already discussed the large amounts of
disk overhead associated with journaling and commitment control.  There
is one other HUGE issue.

It's synchronous.  That is, as far as I know, only one transaction can
be occurring on a file at a time.  You have in effect single-threaded
your entire system around the database, especially as you open up your
commitment control to those multiple-file transactions you're pointing
to as your example.  If, for example, every transaction that hits a
master file record has to lock it, that means that your most popular
item in your shop can only handle one order at a time.

That also begs the design question: when you update an order, do you
lock the item records, too?  Because when you write the item, you should
be updating the allocation quantities on the inventory records.  You're
also updating A/R totals, which means customer records may need to be
locked.  Where exactly do you draw the line at what constitutes a
"transaction"?

Questions like this have some serious ramifications, especially if you
don't design your system to be as fast as possible.  In fact, in order
to make sure you don't lock your database any longer than necessary,
you'll probably have to create shadow records of the transactions so
that you can apply them in the background.  In fact, you may find
yourself doing what SAP does, which is basically chugging all database
updates into a batch queue.

And once you've done that, you have only one program updating each file.
And it does it in batch.  And guess what?

It no longer needs commitment control.

Joe