× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



True, except that we already had the PRPQ Cache Journal whatchamacallit..... I think this gives us the same asynchronous cache commit logic as commitment control.

That is a good argument for those shops reluctant to re-examine their beliefs, though....

Eric

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


Just a quick note here...

But if you already journal your files, then using commitment control SPEEDS UP your application.

You can find out the technical details in the "Striving for Optimal Journal Performance on DB2
Universal Database for iSeries" but basically, when using commitment control the writes to the journal
can be bundled into fewer physical I/Os.

HTH,
Charles


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

Fair enough...

In my current environment, we're already journaling for HA,
so given THIS environment, commitment control starts looking
more desirable.... My past experiences in IT have never
included the use of commitment control, but I fear that this
is just another example of our reluctance to change our minds
about long-held prejudices. For example, just how much
overhead is incurred on a modern i5 when using journaling? I
suspect that with today's speedy CPUs tht the incurred
penalty is quite small. I also suspect that more shops than
ever are using HA replication...

My personal view on this is that I need to understand this
technology better, and that my toolbag has plenty of space in it.

Thanks for the feedback.
Eric

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


From: DeLong, Eric

I too am in the "rarely (if ever) used commit control" camp, but I
would not go so far as to say it's not a worthwhile feature.

Whoa, whoa, whoa. I'm not saying it's not a worthwhile
feature. In my original post to Charles, I talked about
having an option for *NONE, but just as an option. There are
definitely circumstances where commitment control may be
required, circumstances ranging from high availability to
multiple-tier databases. I'm just saying that the nebulous
"standard transaction" in which maybe five to ten files are
being updated doesn't necessarily warrant the overhead of
commitment control.


It IS a standard
transactional control with most database servers, and most other
platforms use this feature to improve the reliability of
the database
and the transactions it supports.

Yup. And I personally have never had a single circumstance
where a customer needed a more reliable database on the
System i. That's not to say databases don't crash. Back in
the day I worked on some databases that used networked tables
(where the RRN was actually the link from one file to
another). Lose one of those tables and you're in for a very
bad day. But I've never needed commitment control on a
System I for any normal application.


If you're saying that System i does not need this extra
safety net, I
might have to disagree. The best application design in the world
could still benefit from a reliable, well proven, efficient
means of
undoing a failed transaction....

It's a design decision. If you want the overhead and you
don't trust your application, then that's fine. But like so
many other things in IT, it's not necessarily a good thing to
have just because you can.


Why do transactions fail? There are probably an infinite number of
answers, some of which can be controlled by the developer,
and some of
which are completely inexplicable. Of key importance is the
developer's ability to identify potential failure points, and to
devise the means to correct these failures.... I'm sure
you'll agree
that, despite our best efforts, it is sometimes impossible to
understand ALL the potential failure points.

Sometimes, sure, but if it's a matter of an RPG program
updating a handful of files, I can indeed identify all
possible potential failure points, ranging from record locks
to abnormal terminations, and I can code for all of them if
necessary. Yes, there are circumstances where commitment
control may be needed, but in my experience those are the
exception rather than the rule.


People talk about checking everything out up front as a way
to avoid
commitment control, and I won't argue that this is incorrect.
However, is that the right approach in all situations? This is, to
me, a lot like the MONITOR opcode. The rule of thumb for
Monitor is
"if you expect high failure rates, monitor becomes inefficient and
should be replaced with an explicit test. Commitment
control grants
protection for the problems that were never considered in the first
place. Is this bad? Testing for a thousand possible
failures for an
event that might never happen seems a bit overkill in most
cases, so
Commitment control seems to be more efficient for handling
these "once in a blue moon" failures.

In order to use commitment control, you have to journal the
files. The system management overhead for journaling is
significant, and in many cases probably outweighs any
benefits from commitment control.

Again, commitment control is not intrinsically bad. However,
it's not intrinsicially better than no commitment control,
either. Like everything else in IT, it's a business
decision, not a religious one.

Joe


--
This is the RPG programming on the AS400 / iSeries (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.




--
This is the RPG programming on the AS400 / iSeries (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.




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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.