Store Web Application Properties in Memory
vunet
I would like to know what are the best practices one could share to
store global properties for a web application. For example, upon
access of this application (i.e. website in classic ASP), I would
store the menu text retrieved from database, application domain to
construct full file paths, admin email, database settings, template
settings, etc.
I tried Application object which kinda works for me but if there are 2
instances of application on one server, things get messed up a bit.
Please suggest your solution.
Thank you.
Bob Barrows
Two instances? Of the same application? That seems to be contrary to the
definition of Application.
Could you explain how things "things get messed up a bit"?
Anyways, you have three alternatives:
1. store the values in a database (including a text or xml file)
2. store them in Application
3. store them in Session
There are no "best practices". The technique you choose depends on the
needs of the application.
--
HTH,
Bob Barrows
vunet
> Two instances? Of the same application? That seems to be contrary to the
> definition of Application.
Yes, for example you can have multiple instances of a WordPress web
application in simply different folders, can't you?
> Could you explain how things "things get messed up a bit"?
Application object in ASP is shared between all web applications.
Let's say I have an account with hosting company. I can create more
than one websites under 2 different folders. If one website is adding
Application("somedata") value, then another one can get Application
("somedata") value when in fact I want this to be different.
>
> Anyways, you have three alternatives:
> 1. store the values in a database (including a text or xml file)
> 2. store them in Application
I already do... but see above.
Bob Barrows
>> Two instances? Of the same application? That seems to be contrary to
>> the definition of Application.
>
> Yes, for example you can have multiple instances of a WordPress web
> application in simply different folders, can't you?
As long as they are not subfolders of a single virtual directory, they
will be considered separate applications, each with its own Application
object:
From http://msdn.microsoft.com/en-us/library/ms525360.aspx
"An ASP-based application is defined as all the .asp files in a virtual
directory and its subdirectories"
Only if the hierarchy looks like this in IIS Manager will they be
considered a single application:
Default Web Site
|
--Wordpress
|
---Wordpress1
|
---Wordpress2
Wordpress1 and Wordpress2 are simply part of the Wordpress application.
If you are thinking each is considered a separate application, then that
is the basis of your problem.
>
>> Could you explain how things "things get messed up a bit"?
>
> Application object in ASP is shared between all web applications.
Err ... no it isn't. See the above definition. Each application has its
own application object.
> Let's say I have an account with hosting company. I can create more
> than one websites under 2 different folders. If one website is adding
> Application("somedata") value, then another one can get Application
> ("somedata") value when in fact I want this to be different.
Have you tried this? I have, and I can categorically say that each
application has its own values in its own application object. On our
companies intranet, I have a website whose host header value is nnwadev.
It contains two folders (plus several others, but they aren't relevant):
acctflashrpt and test. a page called
http://nnwadev/acctflashrpt/applicationtest.asp contains this code:
<%
application("test") = "acctflashrpt test"
response.write "Application(""test"") contains '" & application("test")
& "'"
%>
In the separate test folder I have another page called
http://nnwadev/test/apptest.asp that contains this code:
<%
response.write "Application(""test"") contains '" & application("test")
& "'"
%>
When I run the first page, I see:
Application("test") contains 'acctflashrpt test'
When I then navigate to //nnwadev/test/apptest.asp, I see
Application("test") contains ''
Two folders = two separate applications.
--
HTH,
Bob Barrows
vunet
> Only if the hierarchy looks like this in IIS Manager will they be
> considered a single application:
>
> Default Web Site
> |
> --Wordpress
> |
> ---Wordpress1
> |
> ---Wordpress2
>
> Wordpress1 and Wordpress2 are simply part of the Wordpress application.
It looks like I want to make Wordpress1 and Wordpress2 to be separate
applications even though it is one "application". Thus I cannot use
Application object for my purposes. And I do not want to use database
because this application is supposed to have no database dependency.
So I am left with session object according to your answer. So then am
I supposed to create a bunch of session objects for each property? The
object may have a long string of text (menu html/xml text). This does
not seem to be a very good solution... does it?
Thanks
Bob Barrows
>> Only if the hierarchy looks like this in IIS Manager will they be
>> considered a single application:
>>
>> Default Web Site
>>>
>> --Wordpress
>>>
>> ---Wordpress1
>>>
>> ---Wordpress2
>>
>> Wordpress1 and Wordpress2 are simply part of the Wordpress
>> application.
>
> It looks like I want to make Wordpress1 and Wordpress2 to be separate
> applications even though it is one "application".
Yeah, they can only be separate applications if they are arranged like
this:
Default Web Site
|
---Wordpress1
|
---Wordpress2
> Thus I cannot use
> Application object for my purposes. And I do not want to use database
> because this application is supposed to have no database dependency.
> So I am left with session object according to your answer. So then am
> I supposed to create a bunch of session objects for each property? The
> object may have a long string of text (menu html/xml text). This does
> not seem to be a very good solution... does it?
No. Session is not a good solution for data that is intended to span
sessions. My inclination would be to store it in a file on the server,
especially the xml. The menu html sounds like it needs to be a
server-side include file anyways.
--
HTH,
Bob Barrows
nospam Paal @everywheredotcom Jon Paal [MSMD]
use this approach as a "config" file
the other option is to do as suggested by Bob
Dan
"vunet" <vune...@gmail.com> wrote in message
news:ff52e10b-a281-4908...@j19g2000yqk.googlegroups.com...
>
>> Only if the hierarchy looks like this in IIS Manager will they be
>> considered a single application:
>>
>> Default Web Site
>> |
>> --Wordpress
>> |
>> ---Wordpress1
>> |
>> ---Wordpress2
>>
>> Wordpress1 and Wordpress2 are simply part of the Wordpress application.
>
> It looks like I want to make Wordpress1 and Wordpress2 to be separate
> applications even though it is one "application". Thus I cannot use
> Application object for my purposes.
If your hosting solution allows you to mark the Wordpress1 and Wordpress2 as
ASP Application Roots then you can use the Application object in each and
they will be independent. Applications are not required to be virtual
directories directory under the root directory, and also any virtual
directory under the root isn't automatically going to be a separate
Application. The IIS management interface lets you set Application roots on
any folder anywhere in the tree.
--
Dan
Bob Barrows
Yes, you are absolutely correct. I have now set this situation up on my
web server and each application, as defined in IIS Manager, has its own
application object. Thanks for teaching me something new.
I still submit that some of what vunet is looking to do is more
appropriate for server-side include (ssi) files.
--
HTH,
Bob Barrows
Dan
"Bob Barrows" <reb0...@NOyahoo.SPAMcom> wrote in message
news:e$YkQj1cK...@TK2MSFTNGP02.phx.gbl...
I'm glad I was able to teach you something, but I've got a long way to go
before I get close to what you've taught me :P
> I still submit that some of what vunet is looking to do is more
> appropriate for server-side include (ssi) files.
An SSI would work fine, so long as the variable names (actually Constants
might be better here) are very clearly defined to reduce the risk of them
being changed elsewhere in the application code. With server side caching
the performance difference should be minimal in terms of actual page
execution time, but there may be a memory overhead associated with this; I
can't remember if includes are cached independently of their parents, or
only the final compiled pages are compiled - in the former case an SSI might
actually usually less memory as there is not collection object overhead,
whereas in the latter case having those same variables/constants cached in
memory could use up more if the number of different pages in the application
is large enough.
--
Dan
vunet
>
> An SSI would work fine, so long as the variable names (actually Constants
> might be better here) are very clearly defined to reduce the risk of them
> being changed elsewhere in the application code. With server side caching
> the performance difference should be minimal in terms of actual page
> execution time, but there may be a memory overhead associated with this; I
> can't remember if includes are cached independently of their parents, or
> only the final compiled pages are compiled - in the former case an SSI might
> actually usually less memory as there is not collection object overhead,
> whereas in the latter case having those same variables/constants cached in
> memory could use up more if the number of different pages in the application
> is large enough.
>
> --
> Dan
I think what I am really looking for in an ideal world is a singleton
alternative in classic ASP.
vunet
class MySingleton
public function getInstance(ApplicationID)
if not isObject(application(ApplicationID)) then
set application(ApplicationID) = new MySingleton
end if
set getInstance = application("MySingleton")
end sub
end class
'usage
set instance = (new MySingleton).getInstance(ApplicationID)
Note: ApplicationID may be something unique (for example I could use
website's path with removed slashes) and if 2 websites share one
Application object the code above will handle this by passing
appropriate parameter (ApplicationID).
Bob Barrows
You're reinventing the wheel. You can prevent two websites from sharing
the same aplication object by simply creating an application for each
folder in IIS Manager. See the previous discussion where Dan convinced
me my initial assertion was incorrect.
Your class will have problems if two threads attempt to create
MySingleton simultaneously.
--
HTH,
Bob Barrows
vunet
> You're reinventing the wheel. You can prevent two websites from sharing
> the same aplication object by simply creating an application for each
> folder in IIS Manager. See the previous discussion where Dan convinced
> me my initial assertion was incorrect.
Thank you. My website package will be distributed to environments
which I have no control of - that's why I wanted a simpler solution.
Though it is good to know I could do what I learned from posts above.
> Your class will have problems if two threads attempt to create
> MySingleton simultaneously.
Should I do Application.Lock/Unlock to synch the access?
Bob Barrows
>> You're reinventing the wheel. You can prevent two websites from
>> sharing the same aplication object by simply creating an application
>> for each folder in IIS Manager. See the previous discussion where
>> Dan convinced me my initial assertion was incorrect.
>
> Thank you. My website package will be distributed to environments
> which I have no control of - that's why I wanted a simpler solution.
I would be more inclined to provide a setup program to set this up
correctly than attempt to roll my own. It will require an administrator
on the web server to run the script or setup program ...
But then again, I'm strictly an intranet developer ... maybe this is
something internet developers need to do.
> Though it is good to know I could do what I learned from posts above.
>
>> Your class will have problems if two threads attempt to create
>> MySingleton simultaneously.
>
> Should I do Application.Lock/Unlock to synch the access?
Yes, that is the standard practice.
--
HTH,
Bob Barrows