statefull vs stateless delegation classes

[tom.baeyens]

can we safely assume that all delegation classes are stateless ?

when a process calls out to a user class, this can be done by specifying the classname and some configuration injections. there are various use cases of delegation classes: Assigner's (aka AssignmentHandlers), EventListeners (aka Actions) and so on.

with delegation classes being stateless i mean that execution of those delegation classes will not update their member field. so after construction (incl injecting configuration) they can be considered immutable.

if that is the case, those objects become thread safe and cacheble.

we didn't assume this in jbpm 3 and hence instantiated each object each time as there is no good way of introducing caching.

so...

can we safely assume that all delegation classes are stateless as the default ?

[kukeltje]

I've looked through all the delegation classes I've made the last few years (around 40) and none of them update any member fields.

But that is just me (and probably more by accident then on purpose).... not sure if it is save to assume everybody did this...

[kukeltje]

40 classes that is, not years ;-)

[camunda]

I think it is good practice to keep them stateless as. I also don't remember cases where it is not true. And it doesn't make sense, since you cannot access the changed state later.

But it should be made sure that one action object is only used for one thread at a time, like a pool...

And it must be documented somewhere ;-)

[tom.baeyens]

"camunda" wrote:
But it should be made sure that one action object is only used for one thread at a time, like a pool...

why ? if they're stateless, i don't see the point. then all threads can use the same delegation object, no ?

[jbarrez]

I agree: they should be stateless. And indeed, as a consequence they can be shared by all who needs them.

[camunda]

Tom wrote:

why ? if they're stateless, i don't see the point. then all threads can use the same delegation object, no ?

I am not an expert in Multi-Threading, but multiple threads using the same object with the same method at the same time - doesn't this make problems?

[jbarrez]

Not if they're stateless. App servers for example use the same object (eg a servlet) many many times for several requests

[camunda]

Yeah, but not the same object for two requests at the same time, that's why the have a pool or Servlets or Beans... Or am I totally wrong here?

[roschmel]

If the handlers are reused, I also think they should be used in a pool. Because if you use the same handler object in multiple threads at the same time, the componentes you delegate to must also be thread safe. This can get a llittle bit tricky.

I am also quite sure that introducing resue of handler object will NOT be backward compatible to a lot of handlers implemented out there. For example we are using members of the handler in abstract base implementations to prefetch some data objects for later use in more complex handlers (I konw that implementation inheritance is not considererd good design....).

So if you want backward compatible it must be configurable to use pools or not. I am against using handler objects multithreaded because its makes coding much harder.

[camunda]

Exactly...

[kukeltje]

I was under the impression that if you do not use member fields but only variables local to a method, there is no problem (that is what Joram says)

[camunda]

Okay, I asked a colleage which really knows about multi-threading. Tom, Joram and Ronald are right, it is no problem.

But it is true still that it puts higher requirements on your ActionHandlers (no member fields)...

[kukeltje]

"camunda" wrote:
But it is true still that it puts higher requirements on your ActionHandlers (no member fields)...

100% higher from 0 is still 0 :-)

You can have member fields, in fact they are there since they are populated by the engine via reflection, they just should not change... So it's not that big a deal imo

[koen.aers]

Actually, since at this moment the handler classes are instantiated at each use and thrown away afterwards, the use of them is stateless by definition. So if users use instance variables (fields) to hold variables temporarily they can somehow always be refactored as local variables in the execute method (or maybe as method calls in some superclass as in Robert's case). In these cases the change will indeed not be backwards compatible. The question is whether the performance gain of being able to cache these action handlers is worth the incompatibility. In my opinion it is. Of course, action handlers need to clearly be documented as stateless if we perform this change.

Cheers,
Koen