Caching in the Application Object

[dave]

There seems to be plenty of discussion about caching in the Application
Object, however, I cant find any info on what realistic limitations there
are and how they are measured

What are the factors that will limit performance / storage of many
individual or single large bits of data with application scope?

eg database driven list boxes (that dont require up to the minute data)
10 * 100 options? 100 * 100 options? kb's? megs of info? How much can I
cache? :-)

Cheers

[Egbert Nierop \(MVP for IIS\)]

Re: Caching in the Application Object

"dave" <none@invalid.c om> wrote in message
news:%23p%233Mj mkEHA.3372@TK2M SFTNGP09.phx.gb l...[color=blue]
> There seems to be plenty of discussion about caching in the Application
> Object, however, I cant find any info on what realistic limitations there
> are and how they are measured
>
> What are the factors that will limit performance / storage of many
> individual or single large bits of data with application scope?[/color]

-if- you store objects in the application you should use components without
thread affinity (so no VB6!) or a badly compiled C++ component.
Second, read performance from normal data such as strings and arrays is OK.
But as soon as you start writing to it, you need to lock. So, data that not
so often changes is OK. The limit is the sky, so for readonly data.
[color=blue]
> eg database driven list boxes (that dont require up to the minute data)
> 10 * 100 options? 100 * 100 options? kb's? megs of info? How much can I
> cache? :-)[/color]

No hard numbers. Readonly data is OK.
[color=blue]
> Cheers
>
>[/color]

[dave]

Re: Caching in the Application Object


Yes, for arrays/strings/text only.
So - really nothing to worry about then? sweeet....
(Not that Im going to slap my whole website into the application object or
anything silly... ;-)


"Egbert Nierop (MVP for IIS)" <egbert_nierop@ nospam.invalid> wrote in
message news:uxrDT4mkEH A.2804@TK2MSFTN GP09.phx.gbl...[color=blue]
> "dave" <none@invalid.c om> wrote in message
> news:%23p%233Mj mkEHA.3372@TK2M SFTNGP09.phx.gb l...[color=green]
> > There seems to be plenty of discussion about caching in the Application
> > Object, however, I cant find any info on what realistic limitations[/color][/color]
there[color=blue][color=green]
> > are and how they are measured
> >
> > What are the factors that will limit performance / storage of many
> > individual or single large bits of data with application scope?[/color]
>
> -if- you store objects in the application you should use components[/color]
without[color=blue]
> thread affinity (so no VB6!) or a badly compiled C++ component.
> Second, read performance from normal data such as strings and arrays is[/color]
OK.[color=blue]
> But as soon as you start writing to it, you need to lock. So, data that[/color]
not[color=blue]
> so often changes is OK. The limit is the sky, so for readonly data.
>[color=green]
> > eg database driven list boxes (that dont require up to the minute data)
> > 10 * 100 options? 100 * 100 options? kb's? megs of info? How much can I
> > cache? :-)[/color]
>
> No hard numbers. Readonly data is OK.
>[color=green]
> > Cheers
> >
> >[/color]
>[/color]

[dlbjr]

Re: Caching in the Application Object

Dave,

How I would do this:

To fill the data into an Application Variable.
Read the data from the database into a record set and save to an XML STREAM into your Application
Variable
And store the date stamp when you done it into a Application Variable. This will allow age
management of the data.
When needed to build a drop down or list, then just load the XML STREAM into a recordset and
process. This will run fast and allow you to maintain state of the selected item per client if
needed.

HTH

dlbjr
Pleading sagacious indoctrination!

[dave]

Re: Caching in the Application Object


Would you have an example you could kindly share?


"dlbjr" <oops@iforgot.c om> wrote in message
news:eAl59wokEH A.3772@TK2MSFTN GP14.phx.gbl...[color=blue]
> Dave,
>
> How I would do this:
>
> To fill the data into an Application Variable.
> Read the data from the database into a record set and save to an XML[/color]
STREAM into your Application[color=blue]
> Variable
> And store the date stamp when you done it into a Application Variable.[/color]
This will allow age[color=blue]
> management of the data.
> When needed to build a drop down or list, then just load the XML STREAM[/color]
into a recordset and[color=blue]
> process. This will run fast and allow you to maintain state of the[/color]
selected item per client if[color=blue]
> needed.
>
> HTH
>
> dlbjr
> Pleading sagacious indoctrination!
>
>[/color]

[dlbjr]

Re: Caching in the Application Object

<%
'Most of my code is object based and I will not release needed objects to the news group.
'The code below should give the Idea. If you do not need to maintain state the build the
'dropdown output and store it in the Application variable instead of the XML.This will allow
'you to place the dropdown in code at any time.


'Once you have loaded your data into a record set then pass to this function
'This will load the Application Variable with an XML String. This can be done
'in your global.asa file.
Serialize rs,"AppVarName "

'You can use the code below to load a recordset on any page.
rs.Open Deserialize(App lication("AppVa rName"))
'Build drop done from loaded rs.
%>


<script language="vbscr ipt" runat="server">
Public Sub Serialize(recor dset,strAppVarN ame)
Set mxmldom = CreateObject("M SXML2.DOMDocume nt")
recordset.Save mxmldom, 1
Application.Loc k
Application(str AppVarName) = mxmldom.xml
Application.UnL ock
Set mxmldom = Nothing
End Sub

Public Function Deserialize(str AppVarName)
Set mxmldom = CreateObject("M SXML2.DOMDocume nt")
mxmldom.loadXML Application(str AppVarName)
Deserialize = mxmldom
Set mxmldom = Nothing
End Function
</script>


'dlbjr
'Pleading sagacious indoctrination!