RE: MVC Architecture and transactions

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