AnsweredAssumed Answered

Transaction driven events

Question asked by mishamo on Aug 14, 2014
Latest reply on Aug 19, 2014 by jbarrez

A colleague of mine reported a while ago. I have recently attempted to address the issue myself and thought I'd report on my findings and see if I can get some feedback on the approach.

As a quick summary, the issue was that although an ActivitiEvent may come in to our implementation of ActivitiEventListener, there was no guarantee that the transaction relating to that event had completed so we could not use events to drive UI updates that query activiti services.

The approach I am trying to take is as follows:

- When an (appropriate) event comes in to the listener
- get the command context for the current thread (assuming the event is fired on the expected thread)
- get the transaction context from the command context
- add a listener to the transaction context for

- in the listener, fire the UI update

This seems to work as expected which is great.

The concern I have is that there is no removeTransactionListener method or implementations in the transaction context. This is presumably because the transaction context is thrown away once the transaction is committed.

I would value your opinion on this approach and would like to confirm that my assumptions of events always being fired on an appropriate thread to get the command context from and that transaction contexts are thrown away once a transaction is committed are true.