1 2 Previous Next 21 Replies Latest reply on Feb 20, 2009 4:11 AM by jbarrez Go to original post
      • 15. Re: statefull vs stateless delegation classes
        camunda

        +1

        • 16. Re: statefull vs stateless delegation classes
          aguizar

          Won't caching make expression evaluation in delegation properties unfeasible?

          <delegation class="org.example.Taco">
           <sauce>${actor.sauce.preference}</sauce>
          </delegation>


          If the above is not a requirement (I have wished for it more than once, and not just me, see JBPM-1752) then we can have a single object per process definition. Otherwise we need a pool.

          • 17. Re: statefull vs stateless delegation classes
            fang0x0

            This sounds somewhat like deciding for the user how to use the system.

            Why not add some flexibility - e.g. as with spring, you could point out the scope of the handler (like singleton).

            Pool is good for non singleton handlers (like jsf works).


            About the state in the action handler - we use that to autowire spring dependencies (@Autowire annotation)
            For now we are using only singleton scope, so that's not a problem (if you don't reload spring container), but what if you want to add some custom scope, let's say @ProcessInstance.

            Anyways, it's just an example, the idea is, why add some restrictions, where flexibility is wanted.

            I'm for configurable option, and not globally of course, but for each handler (with sensible default).

            cvl

            • 18. Re: statefull vs stateless delegation classes
              fang0x0

               

              "alex.guizar@jboss.com" wrote:
              Won't caching make expression evaluation in delegation properties unfeasible?

              <delegation class="org.example.Taco">
               <sauce>${actor.sauce.preference}</sauce>
              </delegation>


              If the above is not a requirement (I have wished for it more than once, and not just me, see <a href="https://jira.jboss.org/jira/browse/JBPM-1752">JBPM-1752</a>) then we can have a single object per process definition. Otherwise we need a pool.


              Well, how we solved this, is that we added the layer for all handlers, which injects the properties:

              <action class="com.xxx.jbpm.proxy.JbpmHandlerProxy">
               <handlerName>myHandler</handlerName>
               <propertyMap key-type='java.lang.String' value-type='java.lang.String'>
               <entry><key>myProperty</key><value>#{myVar}</value></entry>
               <entry><key>myProperty2</key><value>#{myVar2}</value></entry>
               </propertyMap>
               </action>


              Not too nice, but usable.

              cvl

              • 19. Re: statefull vs stateless delegation classes
                aguizar

                 

                Not too nice, but usable.

                Makes a good workaround in case pools are ruled out, but I would much rather go for your previous suggestion:
                I'm for configurable option, and not globally of course, but for each handler (with sensible default).

                Pooling would be the "sensible default" if the delegation description contained expressions.

                • 20. Re: statefull vs stateless delegation classes
                  tom.baeyens

                  alejandro, your point is correct. when sharing a single instance, context sensitive expressions cannot be used as they were.

                  i see two options:

                  1) not doing any expression resolution in the injections. only make it possible to inject the static string "${actor.sauce.preference}" in a member field.

                  and then make expression resolution available to the delegation classes through an api method invocation.

                  2) create a property to specify whether a delegation is stateless or not.


                  i'm leaning towards 1) because that is a performant default which users cannot get into trouble with.

                  • 21. Re: statefull vs stateless delegation classes
                    jbarrez

                    1) is the way I'm currently doing it today, but it feels like I'm doing the engine's work by doing so ...

                    Users won't get in to trouble by using option 1, but it certainly overloads the execute method, even if you want to do something simple like adding 2 runtime variables and store the result: first fetch and 'interprete' them, add them, store them ... this is not the jbpm-way

                    Option (2) is a viable alternative, but it's a bit error-prone and hard to debug IMO. Stateful should be the default choice then, and those who want extra performance can set the stateless option where needed

                    So, I'm not liking any of the 2 options ... but if I had to choose, I'd choose option (2).

                    1 2 Previous Next