A colleague of mine reported https://jira.codehaus.org/browse/ACT-2040 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
TransactionState.COMMITTED
- 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.
I also realised that no events seem to be fired after a call to <code>taskService.unclaim(taskId)</code>. Is that by design or an oversight? I suppose I would expect at least a TASK_ASSIGNED event to be fired.
I'm assuming you're referring to the <code>CommandContextCloseListener</code>. In that case, is there any difference between the command context being closed and the transaction context being closed?
