They have been in their current form for “many years”, and are used throughout the engine. Strong chance they are not going to change in a breaking way anytime in your perceived future use.
Thanks for reply @StephenOTT
But I just wondering why not make it a public API, as there is no other way to be notified after transactions is committed which create a need for this to be used a lot.
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
create
assignment (claim, unclaimed)
delete
…
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