5 Replies Latest reply on Jun 25, 2008 8:04 AM by Tom Baeyens

    transient variables

    Tom Baeyens Master

      do we need a similar concept in pvm ?

      transient variables were to pass information from the client to activity implementations. but actually it would be more appropriate to refer to it as a thread-local scope.

      so probably it's better to use the environment scope in the environment for this purpose.

        • 1. Re: transient variables
          Joram Barrez Master

          I've used transient variables in the past for the variables that I didn't need to be persisted (it was for indication of the screen that must be showed).

          Transient variables aren't needed conceptually, since they don't add anything to normal variables from a users perspective. But in my opinion, there are some use cases that would benefit from it so I'm in favor of having them in the PVM too.

          • 2. Re: transient variables
            Tom Baeyens Master

            But there are plain java alternatives:

            * user can use a thread local
            * or the environment context

            • 3. Re: transient variables
              Joram Barrez Master

              True, but then a generic variable retrieving mechanism cannot be used, which is easier for developers.

              Now (with transient vars) you can query the process for a a variable, not knowing if it is transient or not.

              • 4. Re: transient variables
                Jorge Morales Master

                Also it won't be able to use it from within EL. This is very useful.

                • 5. Re: transient variables
                  Tom Baeyens Master

                  the environment serves this purpose. there are multiple contexts in the environment:

                  * the environment-factory context (aka application context) relates to a singleton instance and can also include configuration objects defined in the static configuration file

                  * the environment context. typically this is the same as a transaction context. this also can have objects defined in the static configuration resource. typically those will be transactional resources.

                  * the execution context. this will bind to the process variables in the current process execution

                  contexts are dynamic so more could be added if needed.

                  the idea is that flexible named lookup can be done through the environment. the environment will scan all of these contexts in a certain order (or a given order).

                  that is what EL will be bound to.

                  so that is also what the activities can use if they want contextual lookup of properties.