RE: MVC Architecture and transactions

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Tuesday, August 21, 2007 11:19 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: MVC Architecture and transactions

Honestly, I understand your point about not half-updating the
database, but it seems to me that almost anything that would
break an update is either a serious hardware problem or a
serious programming error, and either one should cause a hard
halt; that's what they're there for.

I don't disagree, but I prefer a "controled" hard halt.

One that doesn't leave my DB half updated, requiring me to not only fix the error but recover the DB.

One big issue, is that RPG can only maintain one record

lock per file.

What happens if you're updating multiple records in the same file?

Well, I don't hold them, which is part of the reason I don't
like commitment control. But I will allow that the more
complex a transaction, the more there are conceivable
circumstances during which in the middle of posting something
could happen that forces a transaction that previously passed
validation to now fail. And for that specific situation, I
can see using some measure of defensive programming, either
using commitment control or some other similar technique.

This is a VERY specific situation and quite rare, in my mind.
For example, can you point to a specific situation in your
business where this can happen? Can you point to a dozen?

The thing is anyplace the validation and transaction are two separate steps could be an issue, just
two users doing the same thing or different things that happen to hit the same records milliseconds
apart.

Sure, its unlikly with 20 users, but how about 2,000 or 20,000?

Can you program around it? Sure, as you've pointed out we havn't always had commitment control.

All I'm saying is that commitment control provides a standard way to handle things you might have had
to manually code before. As a bonus, the ACID characteristics of an application designed to use
commitment control would be better than one where all the ACID characteristics are hand coded.


Correct me if I'm wrong, but I think your one of your biggest arguments against commitment control is
the cost. Namly the DASD space required for journaling and time required to manage it. As other have
pointed out, system managed receivers takes most of that pain away. In addition, you've got the the
MINENTDTA and FIXLENDTA parms to help lower the size of journal entries. Lastly, how many
applications do you have that don't use journaling, but do have various output only audit files to
track who did what when. Sounds like a roll-your-own journal to me <smile>.


Charles




This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.