|
Craig, how does the trigger handle shifting from synchronous processing to
asynchronous? If you are using Data Queues, You may want to look into
MQSeries. Those queues are a bit heavier, but have commitment control built
in. I believe that with MQSeries, a message that is put on the queue but
not yet committed is not available for retrieval. Then you can use
commitment control as needed. You asynchronous jobs do not get messages
until they are committed, and a rollback will remove those messages before
they are delivered.
Rollback should not fire the trigger again because anything that is
processed in the same commitment definition whether by trigger, or by
application will be rolled back by the rollback itself (as long as all your
changed resources are covered by the same commitment definition). If you
are doing commitment control, but not covering all of your bases with the
commitment definition, that is really on you, not the database. It has to
assume that anything you left out of the transaction was intentional. Thus
re-firing triggers is the wrong thing to do on a rollback.
On Thu, Jun 7, 2018 at 10:46 AM, Craig Richards <craig@xxxxxxxxxxxxxxxx>
wrote:
Hi Birgitta,both
I changed the commit scope to *JOB.
I'm seeing the same behaviour as before.
To reiterate...
- Application Program running under commit control ( I tested with
*JOB and *ACTGRP ) updates FILEA ( under commit control )and
- FILEA has an RPGLE *AFTER *UPDATE trigger, not using commit control.
This program runs in the caller's activation group
( For completeness, this trigger program looks at the journal images
if certain fields have changed, builds a JSON message from the dataand
writes to FILEB, then uses QSNDDTAQ to wake an async server whichpicks
upthrough
the message from FILEB and distributes it to other systems )
- After the UPDATE executes in the Application program, stepping
in debug shows it goes straight into the trigger program, whichperforms
the operations described above. Stepping back out of the triggerprogram
and though the main application program and past the eventual COMMITthe
obviously doesn't invoke the trigger again, it's work is done.
- Repeating the process, but forcing a fail and ROLBK this time, it
works exactly the same. The Trigger Program gets called immediately
following the UPDATE, but is not called again after the ROLBK when the
database transaction is rolled back.
Now that I know this is how it works, I can code around it. I'm just
surprised that the trigger is informed about the initial update but not
fact that it was rolled back.because
I understand how I can include the trigger database activity in the same
commit block if I want, but actually that doesn't solve my problem
the write and async process has already happened and can't be reversedbut
it also does not explain why the trigger gets the update but not theCode
rollback. How can the trigger keep things in order if it doesn't have all
of the transactions?
Anyway, I'll just have to take care of more of this at the Application
level, I was just surprised that things do not work as I had assumed.to
Best regards,
Craig
On 7 June 2018 at 12:15, Marco Facchinetti <marco.facchinetti@xxxxxxxxx>
wrote:
Yes using RCVJRNE. And you can complete the circle telling the trigger
thewrite the before image and a timestamp (if program's name match) into asomething
dedicated table. Later you can match journal entries (using id and
timestamp), checking for rollbacks, and do your sync job.
HTH
--
Marco Facchinetti
Mr S.r.l.
Tel. 035 962885
Cel. 393 9620498
Skype: facchinettimarco
2018-06-07 13:00 GMT+02:00 Craig Richards <craig@xxxxxxxxxxxxxxxx>:
Hi Marco,aysnc
Thanks for your comment.
By journal analysis do mean - rather than firing a trigger, having an
process using something like RCVJRNE to read the entries and do
with them based on the program listed there?
If so, it's a good reminder of that technique which I have used in
genericpast. Also I've seen some places set up so that trigger programs donothing
themselves other than shunt the record image(s) to a secondary
usestable where an async process decides what, if anything to do with theprocessing
change.
But we are only journalling After Images and I need both for my
and I've already got a standard process in place which essentially
checkstopQMHSNDPM and QMHRCVPM to bounce up the stack until it either hits the
or finds a program whose name doesn't begin with Q which it then
theagainst an exclusion file. It works fast, doesn't leave messages in
onmarco.facchinetti@xxxxxxxxx>joblog and for the moment at least meets our requirements.
thanks kindly,
Craig
On 7 June 2018 at 11:27, Marco Facchinetti <
wrote:full
Hi Craig, if your decision about update or not doesn't relay on the
call stack but only on write/update program 's name consider usingjournal
analysis.
I found it very usefull especially if updates are really async or
athat
:remote DB.
HTH
--
Marco Facchinetti
Mr S.r.l.
Tel. 035 962885
Cel. 393 9620498
Skype: facchinettimarco
2018-06-07 10:26 GMT+02:00 Craig Richards <craig@xxxxxxxxxxxxxxxx
educationcalling
Hi Dieter (I hope this is the correct name - it seems better than
you D*B )
Thanks again for taking time to post. I do appreciate it.
I will consider your words, if nothing more than for my own
andas
I
haven't looked at commit exit program.
However I will most likely take my previously suggested approach
exclude certain programs from the trigger processing, putting
iscode
in
the application programs.
Here are my reasons for this:
1) I prefer to keep trigger programs as light as possibly. This
kindbebecause
they have to perform as part of the database update and therefore
efficient, and the other reason is that, to me at least, it's
ofthe
business"under the covers" processing. So any heavy transactions or
rules
I tend to port into something like an asynchronous server where
mycode
is
more visible and it's not holding up critical I/O. This is just
viaopinion
and preference, I don't expect everyone to agree.
2) When there is a possibility that the database can be updated
Jobs)DDRA/DDM (QRWTSRVR Jobs) or Database Host Server (QZDASOINIT
connections,which
hang around for a while and get re-used via different
theyoufor
cannot leave the trigger program resident or you are just asking
trouble. Therefore every database access would need to start up
andtrigger
program each time, then the trigger program would have to find
woulddynamically bind in the service program each time, then this isregistering
the exit program each time. I'm sure many, maybe most people
anargue
that this is all find and dandy and just a walk in the park for
myIBMi,
but I'd personally just rather not have all of that going on in
fortriggers
plus the overhead and logic of storing up all of the data ready
I'msomewhen
a
COMMIT is issued. I can see how this approach could work though.
But I'm grateful you took the time to send me your thoughts and
untilinformation I didn't know about before.
best regards,
Craig
On 7 June 2018 at 08:55, D*B <dieter.bender@xxxxxxxxxxxx> wrote:
<Craig>
1) If the database manager held back on the trigger processing
the
commit. Life would be simple. There would be nothing to undo.
declareusing
commit control, that's a declaration that I don't want to
puttingtheinto
transaction over until I commit. Why let processing bleed over
thecommit?
trigger's domain until I've confirmed the transaction with a
</Craig>
... this wouldn't be too hard to implement:
- create a SRVPGM, providing exported procedures:
-- triggerFired, taking the complete Trigger Buffer, just
nothingtheCCEXIT,
multiplecontents to a global variable to store it (if you would have
records in one transaction, dim would help.
-- commitIssued, taking the info of the commit exit program
onlyand
does all needed work of your trigger, if commit was issued and
reinitializes the global buffer variable. In case of rollback,
procedures)initialisation is done.
-- at activation time (first call of one of the exported
register the commit exit by call of the API.
- your trigger programm, only calls triggerFired, doing
and- create a commit exit programm (you'll find QRPGLESRC.CCEXIT
CCEXITthe
needed headerfiles on sourceforge too, as an example). If
isrelated
called,(RPG400-L)
simply call commitIssued of your SRVPGM.
Let it all run in *caller.
that's it!
D*B
--
This is the RPG programming on the IBM i (AS/400 and iSeries)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription
affiliateaffiliateaffiliateaffiliatequestions.
Help support midrange.com by shopping at amazon.com with our
(RPG400-L)link: http://amzn.to/2dEadiD--
This is the RPG programming on the IBM i (AS/400 and iSeries)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our
(RPG400-L)link: http://amzn.to/2dEadiD--
This is the RPG programming on the IBM i (AS/400 and iSeries)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our
(RPG400-L)link: http://amzn.to/2dEadiD--
This is the RPG programming on the IBM i (AS/400 and iSeries)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our
(RPG400-L)link: http://amzn.to/2dEadiD--
This is the RPG programming on the IBM i (AS/400 and iSeries)
--mailing list--
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.