Transaction Listeners stability as an internal API

I faced the same problem mentioned in these posts:

The solution there worked for me but I came through this

Disclaimer: This is an internal API, meaning we do not guarantee any stability with upcoming releases.

So is there a plan to make it a pubic API and what about its stability guarantee?

Thanks in advance,

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?

1 Like

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

Why do you want to count the tasks after those events?