2

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.

Cube
  • 95
  • 2
  • 11
  • Haven't seen this before. Anyway, your error says there is a problem when calling GetNextNumberWithGapsCommit within FUNCLIB_GP_ABS.TRANSACTION_NBR.FieldFormula, so how is it being called there? – qyb2zm302 Aug 29 '17 at 05:05
  • Thx for reply, the function "GetNextNumberWithGapsCommit" and the CI are delivered by Peoplesoft. We just invoke them directly in the AppEngine program. We have no idea why this error occurs... anyway we have re-issued a SR to Oracle for support and still waiting for solution. Any advice is welcome... – Cube Aug 29 '17 at 10:56
  • Please check if your app engine has the DISABLE RESTART flag checked. Sometimes it can hold a state that will prevent the commit section from succeed. Also, is there any custom code on your CI? – Walucas Aug 30 '17 at 14:00
  • ive seen something related happen with IB runs. The GetNext... function defaults to being run on another connection (which allows separate incrementation commits). unfortunately the db engine would terminate the mostly idle secondary connection. we solved this by telling it not to keep alive the incrementation connection. cant remember what the flag setting was but it on appserver. – JL Peyret Sep 01 '17 at 07:33
  • 1
    also AE->CI calls are best not done directly but through a rowset and funclib call. at least whenever loops and CI-initiated rollbacks mix. btw dbflags=8 is indeed what I used for the IB errors. – JL Peyret Sep 01 '17 at 07:36
  • @JL Peyret Already tried DBflags = 0,1,8 in app/process servers but still not ok... – Cube Sep 02 '17 at 00:49
  • 1
    yes, i saw that. in general though, you dont want your CI calls, like **.save()** to be sitting in an AE's execute pcode. this has to do with connections and rollback too. pack up your varaiables in rowset and pass that to a funclib elsewhere. thats just, hard-learned, best practice. whether that would cause the failure on the incrementation, no idea. can you elaborate on the question if your CI calls are in AE pcode or elsewhere? couldnt tell. – JL Peyret Sep 02 '17 at 01:14

1 Answers1

0

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.

ZeusT
  • 515
  • 2
  • 8