Customer is  facing a similar scenario to this reproducer, using clustered EJB Timers and multipod:

where the timer is scheduled (committed) in a different transaction than the process flow, creating a deadlock.

We can see in the traces that a transaction is created when the task is updated (as expected), that the signal is cached and the timer is scheduled by the same thread, so the expectation would be that the scheduling of the timer is registered in the active transaction, but that's not happening. What's happening is that the UserTransaction object returns 6 for Tx status (no transaction) so the EJB timer service is creating the timer within a new transaction, the timer is processed in another pod before the transaction that updates the task is completed (we put a delay to force that). Since both transactions affect the same process instance id, there is a deadlock.

KIE-LOG-node2] STDOUT: Caused by: org.postgresql.util.PSQLException: ERROR: deadlock detected
[KIE-LOG-node2] STDOUT: Detail: Process 92 waits for ShareLock on transaction 789; blocked by process 96.
[KIE-LOG-node2] STDOUT: Process 96 waits for ShareLock on transaction 785; blocked by process 92.
[KIE-LOG-node2] STDOUT: Hint: See server log for query details.
[KIE-LOG-node2] STDOUT: Where: while updating tuple (0,5) in relation "sessioninfo"