Appserver losing Global Shared Var

M

mokeyh

New Member
I am experimenting with appservers (OE 10.1c) and have a strange problem...

My appservers are set to run a startup procedure which they are doing correctly (I am sending messages out to the server log). Within this startup procedure I am running several persistent procedures (common procedures used by our applcation) and storing the resulting handles as New Global Shared Var handles. I am expecting these handles to remain available to the agent until the agent is shutdown.

When I try to run a procedure via one of these persistent handles it works fine - but only the FIRST time. If I subsequently try to run the same procedure I get...

"meterupdval.p Shared variable adm-billcalc-hdl has not yet been created. (392)"

Somehow it seems to have lost the handle/shared var??? Can anyone shed any light on this - am I missing something obvious?

Thanks for any help,

mokeyh
 
Most likely the calls are being issued in two different contexts, eg. different programs/hierarchies.

Don't use shared variables; they are a mess waiting to happen.
 
The global variables are the scoped to the live time of the startup procedure. So when the startup procedure ends (which he does after startup of the appservers) the variables are gone.
You just have to run the persistent procedures and make them super procedures, this way you can call the internal procedures without having to know there handles...

Casper.
 
Interesting, (new global) shared variables work fine for me on a stateless v10 appserver. We still use them because we have to convert a complete app that currently makes extensive use of shared variables from Client/Server to AppServer in (what I think is) record time. Cleaning up or getting rid of the GSVs is something we will assess when the initial split of UI and Business Logic is completed, for which very valid commercial reasons give us only about 2 months to get it all done.

What I did is define the NEW GLOBAL SHARED vars in the Startup procedure of the AppServer and then assign them in the Connect procedure. I happily pass the values from the client to the AppServer as a separated list in one of the parameters and then split that list back into the individual values (of course some minimal validation of these values is done as well to make sure what is passed in makes the grade).

This way I can run the AppServer completely stateles, which gives a huge performance boost to the application, while I don't have to worry about keeping track of context etc. The existing C/S code can then be relatively easily split into UI and BL procedures without having to make too many changes to the logic and so hopefully not introducing too many new "glitches".

With the setup we use the client can hit any appserver instance and will have the shared variables set for the duration of that connection - so that way it should work in your example as well.

Good luck!

Paul
 
We use statefree appserver and have luckily more time to do the same thing... We have one year to split the sources in UI (.NET) and
Progress server part.
We have made a framework which handles context, exceptions, logging, authorisation, datahandling etc... But we still have the shared variables for the same reason. Except they stay server side....

How many screens you have to split?

Casper.
 
Hi Caspar,

We have to do a couple hundred of data entry and maintenance functions, add on top of that a healthy quantity of inquiries and reports... Plenty of work, not enough hands ;)
 
I changed my appserver 'startup' procedure to be a 'connect' procedure instead and this seems to work fine now. I have also added a 'disconnect' procedure to delete all my persistent procedures on disconnect. I thought this might be a bit of an overhead running these procedures for every single connection but it seems to be quick enough.

Thanks for the all assistance. :biggrin:
 
You must log in or register to reply here.
Back
Top