The delete is done lazily outside the transaction since we don't lose transactionality if the delete is lost.
What should happen is on startup, the journalstoragemanager load code should detect the message has been acked from all queues so can delete it / ignore it
I know the TX is not lost and the delete happens outside of the context of the TX.
My point is.. it's taking a while to execute these deletes in the case of a sustained insertion with large transactions.
My suggestion is to always execute these deletes with sync=false. Sync=true here is not guaranteeing you anything.. quite the opposite actually, it will increase the chances of losing these deletes.
Since we need a startup check anyway, I suggest we make sync=false on deleting messages on post-ack, and add the startup check for messages without references.
That's a low hanging fruit for an optimization, as we would release space on the journal faster at those cases.