static hashtable looses its content

[SevDer]

Hi

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

[Peter Bromberg [C# MVP]]

SevDer,
The one thing that pops out at me (and I am sure others will have comments)
is that your sample code shows this Hashtable in a class that derives from
System.Web.UI.Page, implying that it is a web page. The Page class is
inherently unstable in that it is designed to go through its lifecycle and
extinguish itself, therefore by its very nature this appears to be a problem
area. Better to consider storing the hashtable as a static member of the
Global class or in Application state both of which don't normally "go Away".

Hope that helps,
--Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"SevDer" wrote:

Hi

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

[SevDer]

Hi Peter,

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]" <pb*******@yahoo.nospammin.com> wrote in message
news:63**********************************@microsof t.com...

SevDer,
The one thing that pops out at me (and I am sure others will have
comments)
is that your sample code shows this Hashtable in a class that derives from
System.Web.UI.Page, implying that it is a web page. The Page class is
inherently unstable in that it is designed to go through its lifecycle and
extinguish itself, therefore by its very nature this appears to be a
problem
area. Better to consider storing the hashtable as a static member of the
Global class or in Application state both of which don't normally "go
Away".

Hope that helps,
--Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"SevDer" wrote:

Hi

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

[Jon Skeet [C# MVP]]

SevDer <se****@newsgroup.nospam> wrote:

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();
}
<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

[Yuan Ren[MSFT]]

Hi Sevder,

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

[Jon Skeet [C# MVP]]

Yuan Ren[MSFT] <v-****@microsoft.com> wrote:

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.

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.

--
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

[SevDer]

Thank you for the information.

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:MP************************@msnews.microsoft.c om...

Yuan Ren[MSFT] <v-****@microsoft.com> wrote:

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.

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.

--
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

[Jon Skeet [C# MVP]]

SevDer <se****@newsgroup.nospam> wrote:

Thank you for the information.

However can you tell me why AppDomain can be reloaded by itself while it has
processes going on?
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.

--
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