Database Deadlock on YTAB_EXEMPTIONS

[abap-weasel]

Hi Code Pal Team,

we scheduled Code Pal check for large custom code base as ATC run using multiple processes (see bottom right in screenshot). After several hours we noticed deadlock on database YTAB_EXEMPTIONS (see top, bottom left) and we had to cancel ATC run.

Kindly check and advise.

[lucasborin]

Could you please replace the insert_created_on_to_buffer method from the y_object_creation_date class with the following code and test it again?

  METHOD insert_created_on_to_buffer.
    DATA: exemption TYPE ytab_exemptions.

    exemption-object = object_type.
    exemption-obj_name = object_name.
    exemption-created_on = creation_date.
    exemption-as4date_co = sy-datum.
    exemption-is_created_on_buffered = abap_true.

    MODIFY ytab_exemptions FROM exemption.

    is_stored = xsdbool( sy-subrc = 0 ).
  ENDMETHOD.

[abap-weasel]

Unfortunately issue is still happening with MODIFY statement. Also check for record still leads to deadlock. I would expect that a COMMIT WORK after DB operation removes lock. Is it safe to try that or is that not allowed in ATC context?

[lucasborin]

I think it is 'safe' if you are executing the pal code only. However, I am not sure if it will solve the issue. You can try it in your development landscape.

To solve this issue, I can provide you a quick workaround: Disabling the buffer.

You just have to replace the y_object_creation_date with the following one: y_object_creation_date.txt

Furthermore, it looks like this issue will demand a little time/effort since we have to refactor the buffer, and, maybe, split the ytab_exemption responsibility in two as it buffers the object creation date and stores exempted object names.

Ps: Feel free to contribute to the project sharing ideas on how to refactor the buffer routine. :)

[abap-weasel]

I am currently testing your version of y_object_creation_date with deactivated buffer. Wondering about another deadlock on UPDATE DDNTT. Any idea what is happening there?

As only two tasks are blocked by that I still expect the ATC run to finish after some time. Will keep you updated on that, but wanted to let you know the new observation for now.

[abap-weasel]

Unfortunately more and more tasks got blocked again, so I had to abort the ATC run again.

While doing so I did some further investiation. Before I cancelled the task that had HOLD status, I started process debugging in SM50 for first WAIT task. After I cancelled the HOLD task, this is there debugger stopped:

Now I am even more puzzled as I expected to find some workbench/ATC/SCI API but not the INSERT on the ytab_exemptions as that strange DDNTT table was shown in lock monitor. Maybe you can provide some insights on this...? 😕

[abap-weasel]

Well, I have some news on this. I have worked around the issue by schedulung ATC run with a single process. Job completed after about 15 days (yes, days! 😁).

[lucasborin]

I'll try to implement a static buffer (not DB based) using shared memory. I will let you know when the code is ready for the beta test.

[lucasborin]

@abap-weasel: Could you please import the branch database-deadlock and test the version with a static class based buffer?

[abap-weasel]

It took some time, but I can confirm that new version from database-deadlock branch is working. ATC job ran for about 46 hours with 15 tasks.

[lucasborin]

That's a good start. Now, we can work on performance improvement.

[lucasborin]

Solution merged into next version, under branch 1.07.0

[lucasborin]

@abap-weasel: I kindly ask you to open a new incident with a performance trace (high-level is enough) so I can have a look and work on the findings. Besides, I ran it locally and most of the time was in the code inspector framework side and not in the code pal.

Would you mind if I close this incident?

[abap-weasel]

Yeah, fine with me (as change was just merged into master).