RE: MVC Architecture and transactions

Exactly Nathan,

And continuing on the original question: in that use case (to coin a
nice UML/RUP phrase) the business requirement is that the transaction
consists of two files being updated and the business requirement also
states that no matter what, the balances must add up correctly. And
admitted: there are a multitude of ways of ensuring that it does so
without commitment control, using commitment control is one of the
simplest, most widely known and readily available techniques.

Keeping in mind that the multi tiered architectures allow for physically
disconnecting the database from the platform where the actual programs
are running, and that we normally want to develop systems which are
future-proof (so, keeping the impact of changes as low as possible) we
have to allow for this happening. When the database server is on another
machine than the one where the application is running another source of
possible problems -ip routing problems, the beforementioned Yahoo with a
penchant for pulling cords from sockets, etc.- comes in play.

Architecture also normally strives for reusability, and again there are
many possibilities even without CC. CC however offers a way of defining
atomic pieces of database updates which can be combined in endless
variations and still offer a consistent database by the way you define
the transaction size. These can be very granular (every transaction gets
committed) or very course (every 1000 transactions get committed) but
the size of the transaction is, again, defined by the business. The
business weighs the risks against the cost (as previously stated) and
decide whether it is worth the risk of having to run a couple of 1000nds
worth of transactions again (because something happened) or just the
ones that were missed. Both situations can be covered and by placing the
commitment control at the business level you can fairly easily change
the strategy if the pointy heared bosses at the business level decide to
change the strategy. You can also easily throw in another file to be
updated in the same transaction without having to fiddle in the database
access layer.

The actual 'COMMIT' or 'ROLLBACK' statements can be services defined at
the database access layer. To put it bolder: I would advice to do so,
because that makes your application/business layer even less dependant
on the actual implementation of the database access. To put it yet even
bolder: if you do it correctly the programs at the business/application
level can be RPG and without one single F-spec for the database and the
database access level can be native file access, SQL, or yet another
method of file access (existing or yet to be invented in the future).

The original question was where to put the Commit and Rollback (or
rather the place which decides when to make the calls to the commit and
rollback), and I have hopefully pointed out (and argued why) that this
should be at the layer where the business logic is defined. This was not
a question on whether or not CC is a usefull instrument, whether it
could be replaced with yet better instruments or whether it could best
be dropped alltogether.

Phew... I think that will give enough food for argument.. Don't you
think? ;)

Cor

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: woensdag 22 augustus 2007 5:56
To: RPG programming on the AS400 / iSeries
Subject: Re: MVC Architecture and transactions

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?

A good example of this is the banking transaction where the customer
deposits one check, but splits the deposit between more than one
account.

Nathan.