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.
But there are plain java alternatives:
* user can use a thread local
* or the environment context
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.
Also it won't be able to use it from within EL. This is very useful.
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.