The ability to use local variables

[Keith]

I'm sure that I don't fully understand variables and would like some advice.

Suppose I have a Form procedure on which I want to display messages based on data entered.  A message might be: 'Rotational mass (kg) min = 1% of vehicle weight,  max = 30% of vehicle weight, set to default'.  This is just informational.  It is not stored in a database.

For this case can I declare a Local Variable - loc:message1, set it in the server side code and create the session variable viz:

if <certain conditions apply>
   loc:message1 =  'Rotational mass (kg) min = 1% of vehicle weight,  max = 30% of vehicle weight, set to default'
else
   loc:message1 = ''
end
p_web.ssv('loc:message1',loc:message1)

Then, if I Reset Message1 on the Form this should be ok.

But my question is whether there is any possibility that loc:message1 will get changed by another 'user' between when my code decides to post the above message and the execution of the p_web.ssv?

This question stems from the fact that the exe is being used by many users (and all have access to loc:message1).  But if server side code is triggered can that code ever be interrupted or does it always run to completion?  If it always completes before control is passed to another request then loc:message would be safe.

But suppose the server side code contains an IO loop which raises the possibility that the exe will get scheduled off the CPUs will it still run to completion before control is relinquished?  If it does (and loc:message1 is still safe) then that raises the question of the responsiveness of the exe which depends on request being handled in short time frames - but it is possible to write code in the server side that runs for 5 minutes and that would destroy responsiveness for other requests unless it was interrupted (which would make loc:message1 unsafe).

So, more questions than answers in my head - your advice and experience will be appreciated.

Note: When I started this 'message' business I used a file variable but then discovered that if I wanted the message available on multiple tabs then I had to have multiple file variables which seemed cumbersome and perhaps unnecessary.  The above question arises out of my desire to limit file variables (And if someone could tell me how I can use the same variable on different tabs without getting a compile error I would appreciated that too)

Thanks

Keith

[CaseyR]

Hi, Keith

Your local variables cannot be accessed by other users.  They exist only during the execution of the current thread of your session.   Even if you save and restore them between the threads of your form using session values,  they are still limited to just your session.   In fact, if you are doing anything with the local value between threads (pre, generate, validate, post) it would probably be a good idea to use a session value instead if you are not using them to capture user input.

[JohanR]

Hi,


Another thing to keep in mind is that a local variable is like a global variable.

The way I understand it to work.

If you create a local variable on a form called loc:name,
and you have another form using a local variable called loc:name,
the value could persist.
This could be a feature or a problem depending on how they are being used.

So create unique names for local variables per form ,
or make sure they are cleared in the session queue when you're done with them of when a form is init'd.


Johan

[kevin plummer]

Hi Johan,

my understanding is local is local for the life of the thread and global is global for the life of the program. local can be bad because multiple threads fire to create a form and thus your local variable may be blank when you wish to use it.  Session values however are global for the session and thus re-using same session names on different forms some care needs to be taken.

Cheers,

Kev

[JohanR]

Hi Kevin


As far as I know the loc:name is stored in the session queue.
The next form with loc:name will carry that value from the session queue unless it is cleared in the code.

You can't query loc:name, as loc:name only lives for a short time,
but the value for loc:name will be initialised from the session queue when the form is created.

To add, I think this only applies to memory forms, but needs further testing.
Only wanted to point out that it can be unreliable to assume that the local variable is empty.

Johan

[kevin plummer]

Hi Johan,

Yeah I missed your point of actually using it on a form as opposed to just using it in code. It makes sense that it gets added to the Session Q then if it is on a form.

Cheers,

Kevin

[Keith]

Thanks everyone for looking at this.  There are two cases that I want to understand, the first is where there are only a few server side code instructions to execute (and no IO) and the second is where there is lots of IO.

So case1 (my current case):  A user enters a value in a field on a form and I execute a few server side code instructions to validate it.  If it is out of bounds I construct a message in loc:Message1 (a local variable), set the equivalent session variable and reset loc:Message1 on the form.  The message posted is informational only, it is not stored on a database.  Question:  Is this guaranteed to work (is loc:Message1 safe from the predations of other users who may be setting it to blank?

Case2 is hypothetical at this stage.  Same scenario as Case 1 but the server side code contains (out of necessity) an IO loop that takes 30 secs to run.  Is the variable still safe?

I am assuming in all of this that a session spans the whole time a user is interacting with the program until they disconnect and a thread is a specific single request within that session - a thread is what is started to process the server side code or to allow the user to navigate to a new page etc. (I am happy to be told that I am utterly wrong about this).

So, to look at my concern another way - we have one exe which handles all of the sessions and all of the threads in those sessions and that exe is subject to the OS scheduler and its algorithm - the exe can be demoted to the bottom of the execution queue and may not be running at all and when it is scheduled again who gets control and can they clobber loc:message1?

Thanks

Keith

[Bruce]

Hi Keith,

>> Question:  Is this guaranteed to work (is loc:Message1 safe from the predations of other users who may be setting it to blank?
yes

>> Is the variable still safe?
yes. (although there are other issues with having a 30 second delay which we can cover at that time.)

>> I am assuming in all of this that a session spans the whole time a user is interacting with the program until they disconnect
more accurate - until the session times out. The user never disconnects because they are never connected.

>>  and a thread is a specific single request within that session

yes, exactly.

>> - a thread is what is started to process the server side code or to allow the user to navigate to a new page etc.

each incoming request creates a new thread for processing. The thread does whatever the incoming request is instructing it to do, then ends. Typically this all happens in something under a tenth of a second.

>> we have one exe which handles all of the sessions and all of the threads in those sessions and that exe is subject to the OS scheduler and its algorithm

mostly true. Each thread is handled by the OS, not the EXE. But yes, the OS mixes these threads in with all the other threads and allocates time according to its whims.

>> - [a thread] can be demoted to the bottom of the execution queue and may not be running at all and when it is scheduled again who gets control and can they clobber loc:message1?

the local variable, loc:message1 is running on a single thread, so is not shared across threads. (But the lifespan of the thread, and hence the variable is tragically short.)

the session variable is "per session" so users in one session cannot affect the session values of other sessions. (at least not without some very specific code.)

cheers
Bruce

[Keith]

Thanks Bruce, I think I have got that sorted now.

Although the life of loc:message is 'tragically short' because the life of the thread is short  that's only the case if loc:message is not saved in a session variable.  If it is then  it can be resurrected?

And then there is the question of the long running thread because the server side code contains 100K IOs.  You said in your reply that there 'are other issues' - what are they and therefore are there guidelines about how much time can be taken for a single request.  If it is the case that the thread has integrity even through repeated reschedules of the EXE then there should be no problem but if not then I'd like to know the answer.

Thanks

Keith

[Bruce]

>> Although the life of loc:message is 'tragically short' because the life of the thread is short  that's only the case if loc:message is not saved in a session variable.  If it is then  it can be resurrected?

Correct

>> And then there is the question of the long running thread because the server side code contains 100K IOs.  You said in your reply that there 'are other issues' - what are they and therefore are there guidelines about how much time can be taken for a single request. 

The browser will time out if you take too long. To mitigate this do a p_web.NoOp() inside the task.


 << If it is the case that the thread has integrity even through repeated reschedules of the EXE then there should be no problem

Not sure what a reschedule of the exe is, but yes the thread has complete integrity while it is alive. It is not affected by other threads (other than non-threaded global variables)

Cheers
Bruce