|
I disagree Rob.
With "batch" processing of say 100k rows, the natural transaction
boundaries would be either 1 inbound row or all of them.
Even if each inbound row affects multiple tables, performance of so many
small transactions would be very poor. (unless you've got journal caching
turned on)
And if you tried to do all inbound rows in one transaction, that's going to
be too big for comfort.
The best solution is to batch XX number of inbound rows as a single
transaction.
XX should be enough that the journal entries for the affected rows
(including journal entry overhead) comes close to 128KB (IIRC).
Charles
On Thu, Mar 26, 2026 at 10:31 AM Rob Berendt <robertowenberendt@xxxxxxxxx>
wrote:
And that's the thing.thing.
# of transactions should not be your goal. Your goal should be to commit
at the transaction boundary.
The only exception being for some developer using iACS or some such
Did my update, check it out. Either "oops forgot where clause, issuethe
rollback" or "looks good - commit".
On Thu, Mar 26, 2026 at 11:40 AM Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx> wrote:
The other issue with significant numbers of uncommitted transactionswould
be in HA and abnormal terminations of the system.are
If HA/Flashcopy backup and a snapshot is taken at the moment all those
open, when the IPL of the Flash copy will take quite some time, since
amountDB will need to rollback all those transactions before it can call the
database referential integrity good. That could be a significant
ofcommits
time (hours in bad cases).must
The same holds true for a single system if it crashes and has to IPL.
Think about applying PTFs, which ordinarily will cause an IPL. If all
those transactions are still open, the same rules apply, the Database
insure referential integrity to proceed.
In the end it’s bad design and management of the system to leave
midrange-l@xxxxxxxxxxxxxxxxxxopen any longer than needed for the transaction boundary.
Jim Oberholtzer
Agile Technology Architects
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of
Charles Wilt <charles.wilt@xxxxxxxxx>
Date: Thursday, March 26, 2026 at 10:13 AM
To: Midrange Systems Technical Discussion <
thetransaction
Subject: Re: CPF377F Save ended. Unable to reach checkpoint
Yeah, good plan...you really don't want large commits being done.
IIRC, there's actually not a hard system limit...if the system has the
resources it will do it.
But from experience, while committing a large (100K maybe 1M ?)
isn't bad; if you need to roll it back it will take much longer.
Charles
On Thu, Mar 26, 2026 at 5:22 AM Gad Miron <gadmiron@xxxxxxxxx> wrote:
Thanks again guys
This is an home grown Web application that loads EDI files
that can be of considerable size, so it may be still running while
filenightly save kicks in.
Rob's replay got me thinking though,
I'll ask our web developer to commit every NNN records and not at
transactionsend
only.
Txs you all
Gad
date: Wed, 25 Mar 2026 09:55:37 -0400
from: Rob Berendt <robertowenberendt@xxxxxxxxx>
subject: Re: CPF377F Save ended. Unable to reach checkpoint
And some might argue why are people not committing their
andin
a
timely basis? This may be what you really need to do. This may be
difficult in some situations. Thinking on your specific example
developerthe
client based program involved, you might need to train that
mailingtowrote:
changecommit on a frequent basis, or to do their updates WITH NC. Or to
their odbc connection to one which can be defaulted to WITH NC
On Wed, Mar 25, 2026 at 9:36?AM Gad Miron <gadmiron@xxxxxxxxx>
reasons.
Thanks Jim, Rob
I just wonder why IBM tolerates a situation
when an object cannot be saved because it's locked for other
mailing- by issuing a CPF3761 Cannot use XXX in Library YYY
and do not tolerate a locked object by "commit pending"
Gad
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
listrelated
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
--questions.
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
relatedlistrelated
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
listquestions.--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
relatedquestions.list
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
listquestions.--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx--
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2026 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.