Solved

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

Posted on 2003-11-03
15
413 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
Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

 
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

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I recently decide that I needed a way to make my pages scream on the net.   While searching around how I can accomplish this I stumbled across a great article that stated "minimize the server requests." I got to thinking, hey, I use more than one…
I was asked about the differences between classic ASP and ASP.NET, so let me put them down here, for reference: Let's make the introductions... Classic ASP was launched by Microsoft in 1998 and dynamically generate web pages upon user interact…
Internet Business Fax to Email Made Easy - With eFax Corporate (http://www.enterprise.efax.com), you'll receive a dedicated online fax number, which is used the same way as a typical analog fax number. You'll receive secure faxes in your email, fr…
Both in life and business – not all partnerships are created equal. As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …

863 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

27 Experts available now in Live!

Get 1:1 Help Now