-
1. Re: statefull vs stateless delegation classes
kukeltje Feb 18, 2009 8:50 AM (in response to tom.baeyens)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... -
2. Re: statefull vs stateless delegation classes
kukeltje Feb 18, 2009 8:51 AM (in response to tom.baeyens)40 classes that is, not years ;-)
-
3. Re: statefull vs stateless delegation classes
camunda Feb 18, 2009 8:57 AM (in response to tom.baeyens)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 ;-) -
4. Re: statefull vs stateless delegation classes
tom.baeyens Feb 18, 2009 9:13 AM (in response to 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 ? -
5. Re: statefull vs stateless delegation classes
jbarrez Feb 18, 2009 9:18 AM (in response to tom.baeyens)I agree: they should be stateless. And indeed, as a consequence they can be shared by all who needs them.
-
6. Re: statefull vs stateless delegation classes
camunda Feb 19, 2009 6:59 AM (in response to tom.baeyens)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? -
7. Re: statefull vs stateless delegation classes
jbarrez Feb 19, 2009 7:55 AM (in response to tom.baeyens)Not if they're stateless. App servers for example use the same object (eg a servlet) many many times for several requests
-
8. Re: statefull vs stateless delegation classes
camunda Feb 19, 2009 7:57 AM (in response to tom.baeyens)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?
-
9. Re: statefull vs stateless delegation classes
roschmel Feb 19, 2009 8:10 AM (in response to tom.baeyens)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. -
10. Re: statefull vs stateless delegation classes
camunda Feb 19, 2009 8:22 AM (in response to tom.baeyens)Exactly...
-
11. Re: statefull vs stateless delegation classes
kukeltje Feb 19, 2009 10:12 AM (in response to tom.baeyens)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)
-
12. Re: statefull vs stateless delegation classes
camunda Feb 19, 2009 10:16 AM (in response to tom.baeyens)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)... -
13. Re: statefull vs stateless delegation classes
kukeltje Feb 19, 2009 10:21 AM (in response to tom.baeyens)"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 -
14. Re: statefull vs stateless delegation classes
koen.aers Feb 19, 2009 10:26 AM (in response to tom.baeyens)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