As long as there are no asyc activities, jobs or async use of the api involved, the safest place seems to be before you do the last call to the api. Most of the time you know best yourself when this is. But I'm no expert in jPBM 4 yet, so I'm not 100% sure.
The aim is to not have the service aware of how it is being used. The service is returned to jBPM to subsequently invoke method(s), so there is no suitable point in the code to do the thread cleanup.
Imagine that there is some code in jBPM that logically does:
- Get bean from context (invokes the Tapestry/SpringContext in the context chain to get the service bean)
- Invoke service method
<-- here is where we need to do thread cleanup
- Continue with execution
Hope this makes sense.
Sorry should have said there is no suitable place in the service's code or Tapestry/SpringContext. Am hoping there is a suitable hook point in the jBPM code!
Sure there is in jBPM. You can put eventlisteners on all kinds of events e.g. on nod leave etc, but then you'd have it all over you definition. Unless you make 'process-global' eventlisteners. Still, feels kind of dirty. You could also override the jBPM activity implementations and use those. Still, why do you need to do thread-cleanup especially when the thread completes? Aren't all objects destroyed anyway?