Best practice for storing global server variables

[DaveF]

Is there a built-in configuration file for maintaining global variables that live in server memory for the lifetime of the app server? The only time they would need to be reloaded is when the app server is restarted. Here is an example of some of the types of variables I am describing:

1. Various subdirectory paths for storing images and what not.
2. Local task server names.
3. Web and RESTful service URI�s.

I would rather not store these variables in the web project profile and have to re-publish if I ever need to add or change these variables. I would prefer to change the variable information in some kind of config file that resides on the web server and then restart the web server to reload the new variables.

What is the best practice in Alpha for storing server variables in memory so the app server is not constantly reading a config file after every client request? The closest thing I have seen is the Application Server configuration file which is named �ServerConfig.xml�. However, I have been told not to mess with this file even though the documentation says it can be used for this purpose.

Thanks

[aburningflame]

Re: Best practice for storing global server variables

I do remember seeing a 'server variables' in alpha. This may be an option...however, I would do something custom
You have 2 options:

Use mysql and create a system_setting table (Our preferred)
systemsetting.png
-Advantages: Does not require a server restart (only a logout/login if implemented in the way below), System settings can be easily editable if needed, from the application (using an alpha grid component)

Use a file on the server c:/myconfig.txt Or whatever
The c:/myconfig.txt can be formatted however you like, the easiest is probably newline seperated name value pairs
setting1=value
setting2=value2
setting3=5
setting4="C:/image_storage_path"

When the user logs in, redirect to a post_login_process.a5w (set this up in websecurity - set the page after login to post_login_process.a5w)

post_login_process.a5w (This shows the MySQL Example - to read from the file you would use file.open(), while (.NOT. file.eof()) and dim line as C=file.readline() - then you would split line on = , the left would be your variable name, the right would be your variable value and then you can store it in session.

'Note: It would probably be more efficient to call conn.open() and a conn.execute as opposed to calling 5-6 sql_lookups.
'Another option is to call conn.open() and call sql_lookup(conn,.....           - I dont think this opens new connections everytime it is called then. - youd have to look at mysql query logs to see.

if eval_valid("session.batch_build_directory")==.f. then
    'load the batch build directory
    session.batch_build_directory=convert_type(sql_lookup("::name::conn","system_setting","system_setting='BATCH_BUILD_DIRECTORY'","setting_value"),"C")
end if 

if eval_valid("session.contact_name")==.f. then
    session.contact_name=convert_type(sql_lookup("::name::conn","system_setting","system_setting='CONTACT_NAME'","setting_value"),"C")
end if 
response.redirect("index.a5w")
end

[DaveF]

Re: Best practice for storing global server variables

Thank you Scott.

So after the user logs in, you redirect to an interim post login page which loads your configuration settings into session variables and then you redirect to the starting page of your application? This sounds like a good option.

I was looking closer at "application variables" which are stored in the web project profile and "application global variables" which are stored in the web project properties. Both of these variable types are stored in the a5_application.a5i file. This may not be a bad option either if its okay to just re-publish the a5_application.a5i file after making changes to your settings and not having to re-publish a bunch of other system files. This probably requires a server restart, so there are definitely advantages to your technique assuming the settings changes are not significant enough to require users to have to log out anyway. Your technique also allows you to make settings changes through the web application which is a big advantage.

[aburningflame]

Re: Best practice for storing global server variables

So after the user logs in, you redirect to an interim post login page which loads your configuration settings into session variables and then you redirect to the starting page of your application? This sounds like a good option.- Correct

I was looking closer at "application variables" which are stored in the web project profile and "application global variables" which are stored in the web project properties. Both of these variable types are stored in the a5_application.a5i file. This may not be a bad option either if its okay to just re-publish the a5_application.a5i file after making changes to your settings and not having to re-publish a bunch of other system files. This probably requires a server restart - Disadvantages: You are modifying alphas files (possible corruption etc), it DOES require a publish AND a server restart.

so there are definitely advantages to your technique assuming the settings changes are not significant enough to require users to have to log out anyway. Your technique also allows you to make settings changes through the web application which is a big advantage. - Yep, through the web app is a big advantage. - For critical settings changes, you can also announce a maintenance shutdown to your users, stop the app server, change a setting, restart the app server (If you are making a critical system setting change). For a slight system change you can ask a user to logout/login. (In your logout page you should delete your session variables. delete session.batch_directory delete session.contact_name) - Also, the .a5i variables MAY be cached (not sure)

[DaveF]

Re: Best practice for storing global server variables

I did not know about deleting session variables in the logout page for a logout/login situation.

Alpha handles the updating of the application variables in a5_application.a5i, so it should not get corrupted. However, any variables added to ServerConfig.xml is done outside of Alpha and could possibly get corrupted.

Thanks.

[aburningflame]

Re: Best practice for storing global server variables

Well the issue is when you logout, the session variables MAY remain there. It is better to explicitly delete them.
E.g in logout.a5w

<%a5
a5ws_logout_user()
delete session.batch_directory
delete session.contact_name
%>

Just because you call a5ws_logout_user() does not mean the batch directory and contact name variables are cleared. So next time you go to load it using
if eval_valid("session.batch_directory")==.f. it will not refresh the variable because it already exists. By deleting it in logout, you will force the next call to reload the system setting variable.

Of course you can get rid of eval_valid("session.batch_delivery") and just have the line
session.batch_delivery=sql_lookup() 'blablabla

Another option that just crossed my mind is to have a
globals.a5w page - in it.
We use this sometimes, and so do other applications (e.g Yii Framework in PHP has a config.php it reads from)

dim batch_directory as C="c:/batch"
dim contact_name as C="John Smith"

On ALL pages of your application (or pages which require the variables):
mypage.a5w
<%a5
a5w_include("globals.a5w")
?"Contact name is: "+contact_name
%>

This method would NOT require a server restart.
Just an edit to globals.a5w and publish

[aburningflame]

Re: Best practice for storing global server variables

I did not know about deleting session variables in the logout page for a logout/login situation.

Alpha handles the updating of the application variables in a5_application.a5i, so it should not get corrupted. However, any variables added to ServerConfig.xml is done outside of Alpha and could possibly get corrupted.

Thanks.

There is a risk of corruption if you edit the a5_application.a5i file manually (that is what I was referring to sorry).