We have a static hashtable that is located in another tier in our n-tiered
web application.
And we are storing big but not huge objects in this hashtable and the key to
the objects is through Session.SessionID.
public class DataStore : System.Web.UI.Page
{
public static Hashtable ht = new Hashtable();
}
What we expect is, as long as we have the SessionID unchanged, this
hashtable must have the object inside.
In other words, as long as Session is not timed out, we have the value
inside.
And our Session Timeout is 20 mins as usual.
One more important point. All objects inside this hashtable, creates its own
threads for itself, and does its own complext calculations etc. They do not
add/remove items from the hashtable but from themselves.
Now the problem: I made sure that even for 10 minutes of in activity where I
still have the same sessionID, system looses the specific key/value pair in
this hashtable. Simply this key does not exist anymore in the hashtable.
This does not happen all the time. Occurance of this problem is around 2% -
5%.
We don't know why this is happening and looking for alternative ways of data
storage for this object, if we are unable to stabilize this hashtable.
--
Thanks in advance,
SevDer
http://www.sevder.com
Hope that helps,
--Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com
I did get rid of that inheritance, but problem stays, even in my development
machine, I was refreshing the browser and in less than 1 minute, I've lost
the key in this hashtable.
Any other suggestions, like using other ways to store those objects?
"Peter Bromberg [C# MVP]" <pbro...@yahoo.nospammin.com> wrote in message
news:6346C6D5-CF80-4089...@microsoft.com...
<snip>
> Now the problem: I made sure that even for 10 minutes of in activity where I
> still have the same sessionID, system looses the specific key/value pair in
> this hashtable. Simply this key does not exist anymore in the hashtable.
> This does not happen all the time. Occurance of this problem is around 2% -
> 5%.
>
> We don't know why this is happening and looking for alternative ways of data
> storage for this object, if we are unable to stabilize this hashtable.
I suspect that the AppDomain is being unloaded, which means you lose
all the data, static or otherwise. I suspect you'll need to store the
data in a more persistent way.
--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Thanks for your posting!
At your scenario, I think you can store data into a database if the data is
very important for you.
As Jon indicates, there are many reason leads to the current problem. For
example, the AppDomain reloaded, the class recycled by GC and so on. So
it's hard to find out the result. In my opinion, database is good place to
store the data.
Regards,
Yuan Ren [MSFT]
Microsoft Online Support
Just to be precise - unless the AppDomain has been reloaded, the class
won't be recycled by the GC. A static variable should not "lose" its
value within the same AppDomain.
However can you tell me why AppDomain can be reloaded by itself while it has
processes going on? Is there anything that I can do to prevent this?
And, don't you think we will have a huge hit when we switch to database
storage?
Below are our average statistics of the usage of this object and its
contents in a regular day at peak hour:
Actual object init/modify Object data access
per hour ~14500 ~21000
per min ~350 ~240
per sec ~6 ~4
We are also planning to increase our operation volume into a certain level
and in this case we are expecting to have
****10 times**** the above figures.
Now that is why I am scared to go to the database. I feel like, it may lead
to a performance hit, as we will require a lot of modifications, inserts,
deletes which can also lead to a huge table fragmentation etc.
Under these circumstances, what do you think my options are?
Thanks for you help again.
"Jon Skeet [C# MVP]" <sk...@pobox.com> wrote in message
news:MPG.1e1f2a6b9...@msnews.microsoft.com...
What do you mean by "it has processes going on"?
> Is there anything that I can do to prevent this?
Not that I know of. Then again, I'm not an ASP.NET expert. I suggest
you ask about AppDomain recycling on the ASP.NET group.
> And, don't you think we will have a huge hit when we switch to database
> storage?
Possibly. You may be able to mitigate that with caching, particularly
if you don't mind "losing" some of the most recent changes if the
AppDomain is recycled. Presumably the information can't be *that*
crucial, or you wouldn't be able to survive without persisting it
anyway - web applications really should survive a server restart.
> Below are our average statistics of the usage of this object and its
> contents in a regular day at peak hour:
> Actual object init/modify Object data access
> per hour ~14500 ~21000
> per min ~350 ~240
> per sec ~6 ~4
>
> We are also planning to increase our operation volume into a certain level
> and in this case we are expecting to have
> ****10 times**** the above figures.
> Now that is why I am scared to go to the database. I feel like, it may lead
> to a performance hit, as we will require a lot of modifications, inserts,
> deletes which can also lead to a huge table fragmentation etc.
>
> Under these circumstances, what do you think my options are?
Well, you could persist it to a file instead of a database - that
*might* be faster. However, using a database will let you scale up
better in terms of using multiple servers. That may or may not be an
issue in your actual situation.
I wouldn't expect a decent server to have a problem with 60 updates and
40 reads a second, but obviously it depends on exactly what you're
doing. It's worth running some benchmark tests just to see.