4 Replies Latest reply on Aug 10, 2007 10:51 AM by tom.baeyens

    execution propagation

    tom.baeyens
    tom.baeyens Aug 9, 2007 6:56 AM

      execution propagation has been refactored. first a word on the status to be as clear as possible about it.

      the current pvm is stabilizing, many basic execution patterns are implemented but still the heavy ones such as bpel links still need to be demonstrated. issues might still come up at that point that will cause another refactoring.

      for now, i want as much feedback (preferrably from devils:) that point out problems with the current approach. i'll document the basics first and then i'll do a concall presentation on it.

      the returnvalue in the nodebehaviour methods turned out to be a dead end. the reason is that there were way too many returnvalues. so that is why i went back to method invocation for execution propagation. the 'proceed' method makes it possible to write nodes that can be used in transition based execution and block structured execution.

      • 6539 Views
      • Tags:
        • 1. Re: execution propagation
          csouillard
          csouillard Aug 9, 2007 7:49 AM (in response to tom.baeyens)

          Can I start working on ConcurrentExecutionsTest ?

          Charles

            • Actions
          • 2. Re: execution propagation
            csouillard
            csouillard Aug 9, 2007 9:00 AM (in response to tom.baeyens)

            Tom,

            I can see all unit tests are successfull... Only SequenceTest has problems probably due to lock problem...
            Have you this test running on your side ?
            If yes, can you post the code in the forum ?

            Thanks a lot
            Charles

              • Actions
            • 3. Re: execution propagation
              mvaldes Aug 10, 2007 10:22 AM (in response to tom.baeyens)

               

              "tom.baeyens@jboss.com" wrote:

              the returnvalue in the nodebehaviour methods turned out to be a dead end. the reason is that there were way too many returnvalues. so that is why i went back to method invocation for execution propagation. the 'proceed' method makes it possible to write nodes that can be used in transition based execution and block structured execution.


              This is much more natural for us than using NodeState returns. I've also like new features such end, start methods, execution scopes stack as well as execution states. Those concepts were manually handled before in each language extension so I think its great to have them in the PVM.

              I've just updated the CurrentIncomingTransitionTest to add execution status update and check.

              I was now working into more tricky Fork and Join scenarios (Nested forks ending in the same Join). I didn't found yet a way to do that by leveraging ExecutionScopes... I will continue on that.

              regards,
              Miguel Valdes

                • Actions
              • 4. Re: execution propagation
                tom.baeyens
                tom.baeyens Aug 10, 2007 10:51 AM (in response to tom.baeyens)

                i'm pretty happy with what we've got so far as well.

                but there is only one concern left:
                * a node is executed inside an atomic operation.
                * each execution has got its own queue of atomic operations
                * node behaviour can create and operate on another execution. this currently causes the other execution to start a new while loop to perform those other execution's atomic operations
                * so what if that execution in that while loop signals back to the first execution ? that one is still in the middle of an atomic operation... i couldn't figure out why that worked :-)

                but now, explaining it worked therapeutically. yes! now i understand that when a child execution performs another operation back on the parent execution, the operation will just go at the end of the atomic operations queue.

                so the only thing that is left is that you're not sure of the state of your parent execution in the child execution. therefor, you still must make sure that you update the parent execution's state first, and only after that interact with the child execution.

                i'm not explaining it very proper... but it was a great relief. thanks :)

                  • Actions