Manage SessionQueue and ValueQueue

[Robert Iliuta]

Hallo,


It's not very easy to manage this two queue when you doesn't know how NT handle them.. I display in my app some information from SessionQueue ...and I saw strange behavior. From my experience it's very bad idea to store and work with SessionQueue from DCT tables. Bellow it's a scenario:

User table
USE:ID
USE:Name
USE:UserType

When you login you want to story this values from User table in a SessionQueue. Simply you fetch table and then do: p_web.FileToSessionQueue(User) ok, now all values from User table are in a session queue. You can put on the header the UserName , you can filter some browse by USR:ID , you can make restriction by USR:UserType (guest, admin, user, etc..) and you embed like this in your page: <!-- Net:s:USR:UserName --> .ok.
But if you login as admin and try to add a new user (a guest one), and complete the name, type,  and some others fields but then you cancel the form and do something else...now you will have a big surprise. All values you was trying to add are saved and used by your SessionQueue. You will see that your name in header is changed , browse are filtered and all of this because you are a Guest user now. You have to logout and then login again to be admin. And all of this because you was trying to add a guest user and then you decided to abandon the form...NT store automatically all values you complete in a form in a SessionQueue and this values remain there until you will go again to form and add new values or session expires.(they are not local variables....) All the time I was thinking that NT use ValueQueue in a form and not SessionQueue. SessionQueue act like a global variable. Some how this is dangerous. You cannot work with session variables ,...use them in a filter etc..

Maybe was a good ideea to delete all of this variables if a user press cancel and not save button. And also after he save to delete this values from session. I see no reason to remain there. This way we lost control of this session variables and it's not good to use them in application.

A solution to this is to use a prefix like: p_web.FileToSessionQueue(User,,'w-') and now all your variables will become: p_web.GSV('w-USR:UserName') and this way you will not be affected in any way because you have the control and it will never mixed .

I have also a question, where and how is used ValueQueuer? What I was thinking was this ValueQueue are used to store values just for that procedure (like a local variable). But I found in another post that they are available just for that thread...

I would like to know how others handle this and what is the story with ValueQueue?
And YES I would like to read about this in a help/book/manual :-)

Thank you for any suggestion.

Robert

[Bruce]

Hi Robert,

>> Simply you fetch table and then do: p_web.FileToSessionQueue(User) ok, now all values from User table are in a session queue.

yes, but they will be overwritten by the templates during the normal running of the program. ie the FileToSessionQueue method is used internally as well.

In other words, if you want to create and use session variables, then use your own names for them - not the field names of tables. You would be better of creating

p_web.SSV('myID',USE:ID)
and so on and then using p_web.GSV('myID') where you needed it.

>> All the time I was thinking that NT use ValueQueue in a form and not SessionQueue.

The value queue lasts for the length of 1 thread. A single form may result in dozens of threads, so the Form (and Browse, and everytthing else) definitely uses the SessionQueue.

>> You cannot work with session variables ,...use them in a filter etc..

you can (and should) use session values in filters - but if you want a variable for your purposes, then you should create one with your own name - not re-use a dictionary field or something like that.

>> Maybe was a good idea to delete all of this variables if a user press cancel and not save button.

the Cancel button has nothing to do with the problem. The values are changed as you make changes on the form. ie as you enter each value on the form, it is immediately written into the session queue. You could close the browser tab, press ok, press cancel, do whatever you like - but the values are already in the session queue.

>> A solution to this is to use a prefix like: p_web.FileToSessionQueue(User,,'w-')

exactly.

>> where and how is used ValueQueuer?

the Value queue is indeed limited to a single thread. It contains the values of the incoming request, including cookies, URL parameters and post data parameters. In code there are some other uses as well for the Value Queue - basically as a parameter passing mechanism while on a single thread, on the server side.

SessionValues are Session wide.
Values are only in scope for the thread.

There is no "procedure" level variables because on the web "procedures" don't exist - at least not in the way they do in a Windows program. In Windows a procedure is bound onto 1 thread, whereas in the web a "procedure" is simply an event handler for dozens of different events all happening on different threads.

cheers
Bruce