Triggers and commitment control

0 pts.
Tags:
AS/400
DB2 Universal Database
RPG
We are having problems finding a way to get trigger programs included in the needed commitment control boundary. The process starts with a JDBC connection to the 400, and via Java executing processes (SQL) that make changes to the DB files. The files are triggered, and any of the files the trigger programs (which are RPGLE) affect are journaled. There's no problem with commitment control from the Java processes. However, several of the RPG triggers may fire before the Java 'commit' occurs. The problem is then if there's a Java rollback, we are unable to rollback any of the changes made by the triggers fired earlier in the process. It looks like the triggers are basically sitting totally outside the commitment/transaction boundary with their own 'commitment control' status of *NONE. Does anyone have an idea how to bring the triggers into the scope of the process initiating the trigger ? Thanks.
ASKED: September 29, 2005  12:30 PM
UPDATED: November 14, 2009  1:09 PM

Answer Wiki

Thanks. We'll let you know when a new response is added.

In my opinion, you have mixed two tools that realy are not linked.

first is triggers. triggers are on proccess side : for example if you had no triggers, you would have called the progs yourself. A trigger is a program you call, but not directly, you are just the trigger event, is is enough.
I think trigger is outside of the problem

second are commitments. Commit are on data side : it is the tool that permit the global consistency of the information.

I am very surprised by “commitment control status of *NONE” used inside a committed flow of update. I thought is is not possible.
I assume you have checked add files are journaled

Work on having the same commitment level from the beginning to the end of the transaction data flow.

Send a feed-back of your tests, successfull and not successfull. There is still so much 400 site that don’t use journaling, you will have many readers (me included)

===============================================================

It’s perfectly possible to have “commit *NONE” processes inside a commitment boundary. Obviously the files being updated by the triggers are not journaled and therefore probably <i>can’t</i> cooperate with commitment control. Get the trigger developers to fix them.

Simply put, the database is incorrectly implemented. If you want any kind of consistent rollback, the database configuration will have to change. The files will all need to be journaled and the triggers will have to inherit the commitment definition.

Tom

Discuss This Question:  

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following