I don’t work for Camunda, but a guess would be that the engine’s public api is not about the awareness of the DB Transaction, rather it is focused on the business transaction of the execution: thus why the listeners on activities are focused on the Start and End of a activity (not the specific transaction).
What are you trying to accomplish by using a transaction listener?
I need to count tasks for all group users after each type of task listeners
assignment (claim, unclaimed)
Getting the number of the tasks inside the task listener will be wrong in all cases
create: not added yet
claim: still available in the group tasks so counted for other group members
I can take this into account in each case (do +1 or -1) in the appropriate case and for the appropriate users but there may be more cases in the future that we may need to take into consideration.
Transaction listeners can be a single unified solution to all of this but it has a problem that it listens to any commit (not specifically to the commit of the listener I am inside) which also may result in wrong behaviors sometimes.
Which I ask in another question if there is a possible solution for it