RE: MVC Architecture and transactions

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: Nathan Andelin
>
> > If the program is written correctly, the files will get updated.
>
> Programs written correctly?  That can be a tall order.  Some Yahoo will
> come along and place and retain a lock on one of the records within your
> transaction boundary, or forget to set the SIZE parameter on your file to
> *NOMAX records, or mess up some other configuration directive, or push the
> little white button on the UPS...

I still think a competent programmer can handle this stuff, just like we did
for YEARS before commitment control even existed.  Record locks should be
coded for.  SIZE parameter is a recoverable error.  The little white button
is going to cause a lot more problems than just a record lock.


> I agree however that using only record-level-access methods to update
> files avoids most problems.  You can at least test whether you can get a
> lock on all records within your transaction boundary before performing an
> update, and writes hardly ever fail.

Yup.  I guess that's my point.  A well written program doesn't have issues.


> But some SQL programmer will eventually come along and design an
> application to perform set oriented updates using a set oriented user
> interface, and things get more complicated and become less reliable.

Different issue, different day.  Hell, set-oriented updates have a whole
host of problems, including a marked inability to handle things like missing
master records.  The argument is that this is why you have constraints, but
that's yet another conversation.

Joe