I wasn't going to chime in, but now I have to right ;-) My comments are
going to veer off from the answer you are looking for because I am going to
debate the need in the first place.
To be perfectly honest I don't use COMMIT and ROLLBACK in many (if any) of
my applications. I was trying to figure out why and I think it may just
have to do with my approach to writing code. Now, since this is an RPG
forum I will answer according to my RPG experience (vs. Java).
COMMIT and ROLLBACK in my mind are inherently SQL based (stating that out of
ignorance if there is a way to do it with native DB functions like WRITE)
and I have NEVER (as far back as I can remember) used SQL to WRITE (read
INSERT) or UPDATE information to DB2 from RPG. Why? Never had the need -
we already have the best language to DB scenario of any platform I have ever
heard of. On that note SQL is great for *reading* DB2 in the right
scenarios (i.e. ordering of information, adhoc JOINs, etc)
With that said I could see where COMMIT and ROLLBACK _could_ be useful, but
it seems you could program around the need for it in the first place. If
you are doing a big process of inserting and updating records, the typical
RPG approach (in my experience) is to check the rules of the files (i.e.
record existence, data validation, etc) *before* starting a lengthy
update/insert process. The COMMIT and ROLLBACK concept always wants to do
zero work up front and if something "breaks" in the process it is 'easily'
cleaned up with a ROLLBACK.
If I were going to implement COMMIT and ROLLBACK I would do a combination of
what you and your developer are debating. I would have procedures in the
model that started and ended SQL transactions (not even sure how possible
this is with activation groups and the like). The procedures would be named
SQL_startTrans(), SQL_rollback(handle), and SQL_commit(handle) and would be
implemented in the controller layer 90% of the time - as who knows best when
to commit or rollback than the controller that is governing the process to
begin with? The other 10% would be the model using the same API's within
themselves in the event the model layer had a large running process. That
might introduce an issue if you can't have embedded SQL transaction scopes
which is why I put the 'handle' in the above SQL sub proc's.
Again, this is coming from somebody that doesn't really do the COMMIT
ROLLBACK thing but instead incrementally does their DB access.
Those are some of my thoughts,
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Wilt, Charles
Sent: Tuesday, August 21, 2007 8:00 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: MVC Architecture and transactions
Ok,
Really thought this question would get more responses...is everybody to busy
fighting over the cycle?
Scott, Aaron, Joe, Alan, Jon, et. al. Any thoughts guys?
Charles
midrange.com
