Christopher Oliver wrote:

Vadim Gritsenko wrote:

Christopher Oliver wrote:

Vadim Gritsenko wrote:

Is it possible to use application context to share those global variables?


It's possible, but I don't see any benefit over using the session.


Memory consumption. Several people already chimed in that they want to have "session-less" flows.

I don't see how less memory will be consumed if you store it in the context as opposed to the session.


One session object --> at least one hashmap to store attributes, one hashmap to store request parameters, and bunch of other stuff. One hashmap --> at least ~100 instances of HashMap.Entry. Multiply by amount of users and you will get into at least tens of megabytes already.

No session --> no memory occupied by it. You've got tens to might be hundred of megabytes you can dedicate to your cache.


What if those variables *are* global? If they are stored in the session they become local to the current user.

The intention is that they are per-user state, so storing them in the session makes sense.



See example in this thread with var role = .........ROLE;

These kind of variables are not local to the current user. You can also have some other application-wide variables.


The "role" variable itself is writeable (although the value assigned to it was a constant). Thus, it must be per-user.


It must be per-user only if you intend to write into it. Moreover, if it is stuff like poll results, it only harms to store it in the session -- poll results are the same results for all of the users. And I'm specifically talking about flow using application-wide variables, not about per-user variables. Application-wide variables are a nice addition to the "sessionless" flow.



Back to Antonio's suggestion. Can we have a configuration of the flow controller specifying where to store those global variables? Context, session, and request (that should be analogue to "no session", right?) can be possible values.



Where would you specify this, exactly?



Geoff suggested couple of places:


This seems to be a good solution too, as long as it's not once per application. It seems it would need to be on <map:flow> or <map:call>?




I think map:flow is appropriate.


+0 to turning on/off session creation in <map:flow>.


Thanks.


-1 to having "request" or "context" scope.


Any reason for this? -1 requires a reason.

Vadim




Reply via email to