Cache data for a web service in HttpRuntime.CodeGenDir?

Is it advisable to store my own data as XML in the folder returned by
HttpRuntime.CodeGenDir?
(i.e. in "Temporary ASP.NET Files")

Each web service on the server must try to read its own cached file when it
(re)starts.
If it 's not present, it retrieves it from a remote service and caches it
locally.

If it's not advisable, what is the "best practice" for caching global
application data for a (web) service?

re: Cache data for a web service in HttpRuntime.CodeGenDir?

It seems to me that if this is the approach you want to take, it would be
better to keep everything in the same place, e.g. writing the xml to the same
folder the webservice endpoint is in (Server.MapPath("myXmlFile.xml") )
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net




"richlm@nospam.nospam" wrote:

re: Cache data for a web service in HttpRuntime.CodeGenDir?

Hello Richlm,

for global data in ASP.NET webservice, there are several options for you to
persist it. For example, using disk file, using in memory cache, or using
database. If the data won't be quite large that will affect your server's
memory pressure, using in-memory cache would be most efficient. For file
based cache storage, I don't think the HttpRuntime.CodeGenDir (temporary
folder of ASP.NET) is preferred since it is mostly for internal use (such
as the assembly cache, dynamically generated code generation's cache...)
and it is not guranteed that your custom data put there won't be modified
by the internal operations of CLR runtime. IMO, you can consider put your
application's logic cache data in an application specific folder (such as a
sub directory under the App_Data dir of your ASP.NET application). How do
you think?

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

re: Cache data for a web service in HttpRuntime.CodeGenDir?

Hello Steven (& Peter)

Thanks for your input - yes I agree a sub-folder under App_Data is probably
the most appropriate location for a cached file in most cases.

But our "security infrastructure" product installs into existing web
services (which I did not implement or deploy), and the identity of the app
pool in which that web service is running will need write-permissions to the
folder where I cache my data. CodeGenDir is attractive because this must
already be the case.

Another concern is that system administrators might be wary for security
reasons of assigning write permissions to files/folders under the web
service application folder.

A possible solution is to use the last bit of the folder path from
CodeGenDir and store the files under my own tmpfiles folder
e.g. "C:\Program Files\my-company\my-product\Temporary Files"
This will simplify installation on servers where there are many web services
with our product installed - the app pool identities just need read/write
permissions to this folder.

Any comments?

re: Cache data for a web service in HttpRuntime.CodeGenDir?

Thanks for your reply Richlm,

Considered the further deployment and maintenance restriction you
mentioned, I think the program files specific path ( "C:\Program
Files\my-company\my-product\Temporary Files") would be preferred since it
is not a user specific path and won't be affected by another running
process or services.

HttpRuntime.CodeGenDir is still worth a try, however, if you want to put
temporary cached data file there, you need to always perform file existing
cache before you access it because directories and stuffs under that
location is not guranteed to persist all the time(maybe cleaned by other
services of the CLR or ASP.NET runtime).

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

re: Cache data for a web service in HttpRuntime.CodeGenDir?

Hi Richlm,

Any further progress on this or have you got the cache store implemented?
If there is anything else we can help, please feel free to let me know.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.