Peoplesoft : Invalid transaction handle instance passed when saving record by CI in AE program

Question

We are

• using an Application Engine (AE) program
• to save/insert Record GP_ABS_EVENT
• via delivered Component Interface (CI) GP_ABSENCE_EVENT.

The AE program fails randomly. However, it will run to success if we re-run the AE program again with same data.

After debugging, we found the following error message

Fatal SQL error occurred. (2,125) FUNCLIB_GP_ABS.TRANSACTION_NBR.FieldFormula Name:GetNextTransNbr PCPC:143 Statement:2
Called from:GP_ABS_EVENT.EMPLID.SavePreChange Statement:8
Error saving Component Interface. {GP_ABSENCE_EVENT} (91,37)
Internal Error: invalid transaction handle instance passed from SamDestroy 3: 54818 vs 0

which is calling the peoplecode function GetNextNumberWithGapsCommit.

We have tried the suggested action from Oracle (modifying the DbFlags value to DbFlags = 8 in the Application Server configuration) but still cannot solve the problem. We also tried setting DbFlags = 0 and even DbFlags = 1 but no luck.

I have no idea what this error is.

Has anyone encountered this problem before?

Please advise what this error is and how to trace / solve this problem. Thanks a lot!

#Update1

In prod env, we have 2 App servers and 2 process servers which are connecting to a single MSSQL DB.

So far i have tried the following in prod env

• tried set DbFlags = 0 | 1 | 8 in all app/process servers but same error occurs.
• Unchecked/checked DISABLE RESTART in AE

As this issue occurs randomly in prod and i cannot simulate the same problem in our UAT env, i have added the settracesql(3) in the PROD env to see if more detail log can be found when this error occurs again.

Answer 1

The issue here is that the AE and the CI are running on the same thread, but when you save or end a transaction, it is committing to the DB and therefore invalidating your session.

In an AE, you need to have DB commit actions in separate steps from CI save events so the program knows that the transactions are separate.

To get around this, you can prepopulate a staging record with all your new transactions, then use a loop to pump them into the CI. That way you have 'reserved' all your IDs with GetNextNumberWithGapsCommit, and then go ahead and process. This also helps with troubleshooting errors as you have a record of what the process was doing.

In the temp record, ensure you use your process ID as part of the index key so it is fast, and you can isolate to your currently running process.