Threads sharing objects in memory during high volume use

[Ron Mexico]

I have written a graphing engine (very similar to what BigCharts.com
offers). Basically, it's an ASPX page that accepts parameters and calls
back-end business objects (dlls) to create a graph. When the graph is
created as a jpeg, it is returned to the browser as binary data. When it is
used at a low volume, it performs great and returns correctly drawn graphs
in a timely manner. However when the amount of traffic is increased to a
high volume, the graphs come back distorted. I've done some research on this
issue and have found that when .NET creates an object in memory, it is not
thread safe. For instance, if an ASPX page gets called several times at
once and each call creates an object called oGraph, it will create several
oGraph objects. However, when an instance of the ASPX page goes to reference
the properties or methods of oGraph, it doesn't care about which instance in
memory that it uses. It will use one that it didn't create. What I end up
with is mutated graphs. For example, if two calls were made simultaneously
to create a 90 day IBM graph and a one day intraday MSFT graph, I will end
up with a graph with IBM as the title and a plot that reflects MSFT intraday
data. Many times it just looks like pieces of one graph drawn on top of the
other. Does anyone know of a way to tell the ASPX page (and the objects it
calls) to 'mind it's own business', so to say, and only use the specific
instances of objects it initiates? I have tried using
System.Threading.Monitor.Enter\Exit on all of my objects and have also tried
the SyncLock blocks, as well. Any help with this would be greatly
appreciated.

 

[Bruce Barker]

you don't say which graphic library you are using. is it thread safe? (many
aren't). did you use vb module fields? these are not thread safe. by default
asp.net is thread safe, and object instances are local to the the running
thread.

-- bruce (sqlwork.com)

 

[Ron Mexico]

Thank you for the quick reply, Mr. Barker. I am using the graphics library
that comes with .NET (GDI+, I guess) System.Drawing.Graphics and
System.Drawing.Bitmap are the objects. If ASP.NET is thread safe by
default, how else would I be getting combined images? Here's a more
descriptive explanation of how the application works: There are basically
three 'layers' to my application.

1. The ASPX page. All it does is take the parameters from the querys
string and create a new instance of the SecurityGraph object (an object I
wrote) and set some properties (Ticker symbol, plot color, graph
height/width, frequency, etc). The SecurityGraph object has a Generate
method. The last thing the ASPX page does is call that method.

2. SecurityGraph. When the Generate method is called in the SecurityGraph
object, the database is queried based on the information set in the
properties of the SecurityGraph object set by the ASPX page which are loaded
into the new instance of the MWGraph object.

3. MWGraph. This object is where the graph actually gets drawn using the
Graphics and Bitmap objects.

So if ASP.NET is thread safe, I'm guessing the only thing that can be
happening to cause the output of several graphs to have shared properties is
because GDI+ isn't thread safe and the Graphics and Bitmap object are being
shared when several graphs are being created at once by the same
aspx-invoked chain of SecurityGraph and MWGraph objects?

As for 'vb module fields', I'm not quite sure what you are referring to.
Please explain further. Thanks again.

 

[Bruce Barker]

the .net graphics library is thread safe (but not completely multithreaded -
just a performance issue). your code must not be thread safe.

you either have static (shared in vb) variables, or you used a vb module
variable (a member variable defined in a vb module), instead of instance
data, which has led to your problem.


-- bruce (sqlwork.com)

 

[Scott Allen]

For instance, if an ASPX page gets called several times at
once and each call creates an object called oGraph, it will create several
oGraph objects.

Yes, assuming oGraph is not defined with the Shared keyword in VB.

However, when an instance of the ASPX page goes to reference
the properties or methods of oGraph, it doesn't care about which instance in
memory that it uses.

If oGraph is defined as a field in your Page derived class, then a
page instance will always reference the same oGraph object.

It will use one that it didn't create.

You'd only see this problem if oGraph is Shared among multiple
instances, or perhaps you have shared / static fields inside of
oGraph. Perhaps you could share your code?

 

[Patrice]

Looks like you are using a variable that is shared accross sessions. Do you
use a member tagged with the "static" (in c#) or "shared" (in VB.NET)
keywords ?

Those variable are shared accross the whole application and in the case of
ASP.NET it means accross users (as in ASP.NET it's a single application used
by multiple users).