Possible deadlock when recording rollback events

[RoyCurtis]

There might be a deadlock bug that happens whilst:

• The main server thread is recording to the data_rollback table, at the end of a rollback operation, to mark which actions have been rolled back
• The recording task, in an async thread, is recording actions that are happening in a world

When triggered, the entire server is hung and has to be killed. This bug is not triggered all the time; it appears to be random after a rollback.

Evidence

This issue was reported by @pugabear, who provided two logs of when the server hung after a player performed a rollback:

• Hang 1 triggered by commands /pr pv rb p:FlappyPorkwipe a:break r:10 t:240d and /pr pv apply
  • Two other rollback operations were performed; once before and once after this hang. Both completed successfully without incident
  • Abbreviated log of hang 1; note that both threads are hung on reading data from MySQL
  • Entire log of hang 1
• Hang 2 triggered by commands /pr pv rb p:Jason_BourneX,Mario_C123,MrBstriker a:break t:200d r:20 and /prism preview apply
  • Abbreviated log of hang 2; note that both threads are hung on reading data from MySQL AND are holding locks on the same objects
  • Entire log of hang 2

Theoretical causes / questions

• Could it be caused by code added from this commit?
• Is the rollback code supposed to be executing in the main thread? Are ANY Prism SQL operations supposed to be running on the main thread?

Theoretical solutions

Try moving the rollback code to run in the same thread as recording tasks.

Notes

• I am making a lot of assumptions here, as all I have to go on are two crash logs. It's entirely possible something else is to blame (e.g. server configuration, other plugins)
• I've not personally hit this bug yet. Has anybody else, aside from @pugabear, had GPrism hang the server after a rollback?