repost: threading architecture approaches for a shared object, multiple opinions desired

[Jon Sequeira]

I'm have a class that represents shipping cost data for a commerce web site.
The underlying data may only change once a month, maybe less, so I'd rather
not hit the database every time the class is needed.

My concerns are these:

I want it to be thread-safe for any number of simultaneous sessions.

I want it to be efficient-- is making one object available to potentially
hundreds of simultaneous sessions an inefficient approach?

When that infrequent update happens, how can I dereference and
re-instantiate the object based on the new data without fear of messing with
threads that are currently using it?

Any insights are appeciated. Thanks.

--Jon

P.S. Hey Microsoft folks! Threading is such a complex issue, and .NET makes
it new territory to all us folks coming from VB6... I bet a
microsoft.public.dotnet.threading newsgroup would be much appreciated.

 

[Sandy]

And it's a complex answer. I would recommend a COM
object using object pooling. You can have a separate app
that can notify the COM object that data has changed
(through a COM subscription) and the original object can
refresh its data from the database without
reinstantiation.

GL,
Sandy