"polastine" <no***@example.comwrote in message
news:ej**************@TK2MSFTNGP06.phx.gbl...
Hi Anthony --
Anthony Jones wrote:
- ASP.NET uses one thread per HTTP request, correct?
Yes. (Although code responding to thread may spin up some of its own)
OK, figured as much. I'm not forking any threads myself.
If you've placed hashtable into the cache you will need to lock an
object
(which can be the hashtable) before reading or modifying. (BTW, what
framework version are you targeting?)
2.0, currently. Why? Is there a difference/advantage? I can probably go
to 3.x if there's a good reason for it.
Hashtable is old hat (.NET 1.1). Unless you've got some really good reason
use collection types from System.Collections.Generic instead of
System.Collections. If you are able to goto 3.5 then you should.
- To follow the above, I assume I do have to lock anything that might
be
accessed at the same time from two or more concurrent requests?
Typically you would cache immutable content. There is no need to lock
such
content.
By immutable content do you mean a string (as in the example below)?
The purpose of the cache to store values that a costly to re-construct (such
as data created from querying a DB).
The stored values are not expected to change. It may be that they expire or
are invalidated and are therefore droped. Storing a hashtable the contents
of which is to be modified over time would not be in keeping with the cache
purpose. On top of which you would not want it to be dropped from the cache
so you would want to add it to the cache with the NotRemovable priorty, in
which case you may as well use a static field to hold the hashtable and not
bother with the cache at all.
- When accessing properties of a class that contains only static
property accessors, do I need to lock?
Again it depends on whether the underlying fields may be modified. If
so
then yes, the set of fields available to static properties and methods
are
common across the app domain so changes to them need to be synchronised.
OK, but wait. Does that mean that if the fields are not being modified
then there's no risk of a collision between two different request threads?
Yes, nothing will break if all you are doing is reading content that never
changes.
Yes you need locking. However you need to consider whether the such
operation is expensive enough or called often enough to be a real
concern
form a concurrency POV.
Well, I'm not sure about it. That's the problem. In a situation where
I'm serving just a few requests per second, a sub-millisecond lock is
probably not a big deal. But what's the impact for an app pool that's
serving lots of concurrent requests?
Define lots? How many properties will you reading per request and will they
each need to be individually locked?
Are you sure the lock is only sub-millisecond may not in be sub-microsecond?
To a large degree what you actually need to do comes down to the detail of
you design. For example could a bunch of properties be stored together in
structure (a value type) once aquired (under lock) the values in the
structure an be used without a lock.
How do you know you can't afford to lock?
I don't, that's why we're having this conversation =)
Unfortunately there isn't a known rule of thumb that can help, it really
does depend on a many factors such as how much code needs to run under a
lock.
There are two things you can do: design out the mutable shared values and
keep the amount of code running under a lock as small as possible. Usually
the latter can be just the assignment to the shared store that needs a lock.
I doubt you will need to do anything super clever because of contention
problems.
If you goto 3.5 you can use the generic SynchronizedKeyedCollection if you
remain with 2.0 then I would say you need to create a synchronising wrapper
for the generic Dictionary. Don't bother with the Cache and hold this
object statically.
OTH if what you are really doing is holding HTML fragments the perhaps you
should be using the cache directly (not storing a collection in the cache
but storing stings containing HTML). Learn how to set up expiration and/or
dependancies so that stale or defunct entries are dropped.
--
Anthony Jones - MVP ASP/ASP.NET
