Topic by RobertP
Content
I am using custom processes for the incident_update event. Given a certain status, the php code creates a new answer object, fills in some fields, copies the incident thread notes to the answer question, and saves the new answer.
Sometimes, the new answer gets created, but is relatively slow. But subsequent new answer saves happen relatively quickly.
For example - I have a test incident with 5 thread notes. In the log entries below, I copied the test incident to a new incident and saved. I then changed the incident status to Submit PR (which will cause the event code to create the answer), turned off Send on Save, and saved the incident again. I did this three times in a row, which should create a new answer with the identical data. As you can see in the first cycle, it took almost 2.79 seconds to save the new answer. But the second and third cycles, it only took ..32 seconds and .13 seconds for the answer save.
Although I don't catch any exceptions and can't find any log messages anywhere, I think this delay sometimes causes the incident_update event to exceed 5 seconds and it fails to complete my incident_update event handler.
Is this initial delay caused by some sort of caching of the answer table? i.e. the first save doesn't have a cached answer table?
Is there any way I could speed up this initial save?
Could this be concurrent transaction problem? i.e. the answer table locked for another answer create or answer update? Do I need to worry about table locking or concurrency with custom processes?
By the way, after the answer is created, the code creates a task entry to link the incident to the answer.