From: Wilt, Charles
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?
I don't have a good answer, because this is entirely design specific. As
Aaron points out, a lot of RPG programmers don't do any COMMIT/ROLLBACK.
But I'll make a couple of points. First, to Aaron's point, commitment
control works fine with non-SQL data. The downside is that it requires
journaling the files, which has potentially serious consequences in terms of
disk space. Locking was also an issue; if your commitment boundary includes
a customer master record, everyone else is locked out of that customer.
Next, when do you use commitment control, if you do use it. This is an
interesting point. Should you use commitment control during transaction
editing? I think that depends on your application. If this is an
interactive transaction with a user at one end and you have an editing phase
followed by a submit for processing phase, then I wouldn't do it.
At the same time, all editing needs to be re-applied when the data is being
updated, in case the database has changed in the meantime. Which means to
me that the commitment control needs to be one level higher than the
transaction editing, so that you can turn it on or off as needed.
What it comes down to is that I think Aaron's idea of a commitment control
handle is appropriate. This allows the controller to handle the commitment
boundaries. However, in a completely flexible environment, I'd probably
want the ability to specify some special handle values: *NONE to turn off
commitment control entirely, or *AUTO to allow each transaction to commit
itself.
Joe
midrange.com
