Solved

Storing Custom objects (class) and/or Scripting.Dictionary Objects in Application.Object Variablers

Posted on 2003-11-03
15
409 Views
Last Modified: 2012-08-13
I am making a multilanguage script for a forum and was thinking of reading language files with filesystem object once per language, store the content in either a array or a scripting.dictionary object, which I then stored in an application.object variable. My idea was to load each language from the application variable across users sessions. So if UserA loads a page with language 'french' he would load the content of Application.Contents('french_language'), and german in its ovn memory location, english in its own, etc....

I though this would be faster than having each user use a filesystemobject to parse a languagefile for each request.

So my question is: Does anyone know how storing a Scripting.Dictionary-Object in an Application.Object will reduce performance? Will using an regular array be a much faster solution? Will storing a custom class/object work as fast as a regular array, providing the selfmade class doesnt contain any ASP objects itself?

(I though perhaps writing a selfmade class would be better for storing the language and perhaps any related headerinfo).

Thank you for reading!
0
Comment
Question by:skaue
  • 6
  • 4
  • 3
  • +2
15 Comments
 
LVL 46

Expert Comment

by:fritz_the_blank
ID: 9670592
I would recommend the array method with a twist:

When you are finished working with the array, use the Join method to convert it to a string and store the string to a variable. When you need the array again, use the spit method.

Now, since you are only storing strings, you don't need to worry so much about saving an array, object, and etc. that might hurt performance.

Fritz the Blank
0
 
LVL 1

Author Comment

by:skaue
ID: 9670657
Yes, that would work as well. Not a bad idea. Thank you. :)

But I would also like to know how much it would hurt performance storing more advanced "stuff" in the application variable. Nowadays the capacity of the webservers are so good the hunt for writing fast and mimimized code almost are set aside for more functional code. Functional for reading and working with.

But the string idea is very good. I didnt think of that.... Might wanna let the first position be the languageID :P
0
 
LVL 46

Expert Comment

by:fritz_the_blank
ID: 9670740
I have never stored objects or arrays in session or application variables, so I can't really tell you what might happen if you do. I suppose that you could try it both ways, hit the server alot and watch the task manager to see what is what....


Fritz the Blank
0
 
LVL 1

Author Comment

by:skaue
ID: 9670850
yes, well I dont have physical access to the server. Its a webhost. But I thought someone would have some core knowledge on how the IIS handle these things. I've read several place that storing connection objects (or any ADO objects for that matter) in session or application variables isnt smart, due to performance. And that have made me think twice about storing my own objects in session or application objects. I recon there are no limitations on how long a string stored in the application variable can be, other than what the server hardware limit.
0
 
LVL 46

Expert Comment

by:fritz_the_blank
ID: 9670929
Let's put it this way--

An array or dictionary scripting object with the same number of items as a delimited string will most certainly cripple performance earlier!

My understanding is that storing such items in in application variable is not quite as bad as doing so in a session variable as the latter will be unique for each user while the former stays in place as long as the application is active.

Either way, I have stayed away from it and store only simple strings, dates, integers, boolean values, and etc. to these variables.

FtB
0
 
LVL 1

Author Comment

by:skaue
ID: 9671068
well, I'm gonna wait a little while on this one before I accept your string suggestion as full answer (if you dont mind)... ;-)

Would be cool to see if anyone else has some experience with this issue.
0
 
LVL 46

Expert Comment

by:fritz_the_blank
ID: 9671116
That sounds fine by me.

I know that many people take an extreme position against the use of session / application variables altogether, but I think that probably is overdone. On the other hand, I have always drawn the line at storing anything other than simple variable types.

In  regards to my approach, you might want to create a pair of funcitons that transform the data back and forth from a string to an array and keep those in an include file. If you do it that way, you almost get the same simplicity of storing an array without the overhead.

I'll keep my open here in case anyone has something to say that I haven't thought of.


FtB
0
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 21

Expert Comment

by:ap_sajith
ID: 9676180
I wouldnt suggest storing any objects with application scope. It is gonna affect performance and scalability. In ASP, it is always advisable to Create Objects Late and Release them as soon as the processing is done. Basically, You wouldnt be able to make use of object pooling anymore if you tie down objects with session/application scope. This is a simple explanation of why you shouldnt store objects with application scope. If you want a more descriptive information (Explains Thread affinity, scalability issues etc in detail), read through this NICELY written article...

http://www.learnasp.com/advice/dbsessionapp.asp

BTW.. The Dictionary object is apartment threaded and it is not at all advisable to create Apartment threaded objects with application/session scope..... Read more @
http://www.aspfaqs.com/aspfaqs/ShowFAQ.asp?FAQID=129
http://www.websupergoo.com/asides/asp-threading.htm
http://www.asp-help.com/objects/crtc80qb.asp

Cheers!!

0
 
LVL 1

Author Comment

by:skaue
ID: 9676908
Yes, I've seen several articles warning against placing apartment threaded objects in session or application scope. But I've never seen an actual line stating this rule apply for selfmade objects/classes.

Does the same rule apply for example this class:

[code]
Class clsMyClass

Private pstrSomeString

Private Sub Class_Initialize
pstrSomeString = "This is neat object"
End Sub

Private Sub Class_Terminate
End Sub

End Class
[/code]

Then...

[code]
Dim objTest : objTest = New clsMyClass
Application.Contents("theobject") = objTest
[/code]


I can only assume the rule does not apply for arrays, though as ftB recommended string, which isnt such a bad idea :)
0
 
LVL 21

Expert Comment

by:ap_sajith
ID: 9677220
But still... it doesnt make sense for you to use an application scoped class/ object unless you use them in say atleast more than 50% of the pages. Other wise.. its just taking up server resources un necessarily. Page scoped objects are best for ASP.

Cheers!!
0
 
LVL 21

Expert Comment

by:ap_sajith
ID: 9677223
But still... it doesnt make sense for you to use an application scoped class/ object unless you use them in say atleast more than 50% of the pages. Other wise.. its just taking up server resources un necessarily. Page scoped objects are best for ASP.

Cheers!!
0
 
LVL 1

Author Comment

by:skaue
ID: 9677494
Yes, I wouldnt use Application Scope unless its really necessary. As I've explained in the (long) intro to this thread, the usage here is for storing language values across user sessions. So all french users will load output variables from the "french" application variable, and dutch from dutch, english from englich, etc.... and it will be used on 99-100% of the pages.

:)
0
 
LVL 15

Accepted Solution

by:
deighc earned 250 total points
ID: 9677505
There are definitely caveats to storing objects in Application or Session variables but my opinion is that, in some circumstances, this can be an appropriate choice.

I don't like storing objects in Session variables because, under heavy load and with many concurrent sessions running, memory/performance issues can soon arise. But I've used Application scoped objects with no problems. You should only use free-threaded objects at Application (or Session) scope and this will limit what you can use (as ap_sajith has already mentioned, the Dictionary object is appartment threaded so this would be a no no).

The only object I use at Application level (and it may well prove useful in your original question) is a free-threaded XML DOM. The latest version of the MS XML parser allows you to created free-threaded objects and the performance is very good. I often use it to store frequently accessed configuration data and it works very well.

> it doesnt make sense for you to use an application scoped
> class/ object unless you use them in say atleast more than
> 50% of the pages

I agree but I think it's a fair assumption that language-specific text will be used on ALL pages so maybe storing this information at Application level is a good idea.

I'm not trying to dispute the opinions and ideas of others who have posted answers and suggestions to your question but I can tell you that objects CAN be safely used at Application level.
0
 
LVL 28

Expert Comment

by:sybe
ID: 9677655
>> Yes, I've seen several articles warning against placing apartment threaded objects in session or application scope. But I've never seen an actual line stating this rule apply for selfmade objects/classes.

The thing is that you self-made Classes are not persitenet, they are *ALWAYS* destroyed at the end of the page, and there is no way you can save them in Session or Application variables.
0
 
LVL 1

Author Comment

by:skaue
ID: 9677668
Thanks for that reply deighc... in a good way it answeres what I was precicely looking for, and your MS XML parser was a very good example. In fact I've been considering storing "frequently accessed configuration data" myself from perhaps an Application variable.

Very good indeed! :D
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

I have helped a lot of people on EE with their coding sources and have enjoyed near about every minute of it. Sometimes it can get a little tedious but it is always a challenge and the one thing that I always say is:  The Exchange of information …
Have you ever needed to get an ASP script to wait for a while? I have, just to let something else happen. Or in my case, to allow other stuff to happen while I was murdering my MySQL database with an update. The Original Issue This was written…
Excel styles will make formatting consistent and let you apply and change formatting faster. In this tutorial, you'll learn how to use Excel's built-in styles, how to modify styles, and how to create your own. You'll also learn how to use your custo…
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

708 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now