Database Server Too Busy. Advice needed on opening DataContexts

I have this h开发者_JS百科uge system started running yesterday. Thousands of people connecting simultaneously.. I'm Using SQL Server 2008 and .NET 3.5 (C#);

Today I noticed my db server was getting really slow (btw the server machine is really, really capable of handling like 10x this application with ease, so I must be messing up my connections or something).

First of all: My Business classes are creating the only one DataContext each. On class level, like this:

public class BusProduct : IDisposable
{
    //DataContext
    DBDataContext db = new DBDataContext();


    //Variable of type DAL.Products (that will be set on application level)
    public Products _attributes { get; set; }

    //Dispose
    public void Dispose()
    {
        Dispose(true);

        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            db.Dispose();
        }
    }

    /// Constructor
    public BusProduct()
    {
        try
        {
            //New object
            _attributes = new Product();
        }
        catch (Exception ex)
        {
            throw new Exception(ex.Message,ex);
        }
    }

    public void Insert()
    {
        try
        {
            //Insert data set on _attributes
            db.Products.InsertOnSubmit(_attributes);
            db.SubmitChanges();
        }
        catch (Exception ex)
        {
            throw new Exception(ex.Message,ex);
        }

    }

}

What do you guys think about this (One DataContext per class)? What would you suggest? Is it good for huge classes? Is it even good?

I Like to make it like this mainly because of returns like IQueryable<Type>. (When trying to access this kind of return, if I use one DataContext for each method, it will already be disposed)

What do you guys think about this (One DataContext per class)?

What you do is wrong on so many levels it isn't fun - for example, how do you sync updates on multiple classes in a transaction? A distributed transaction for 200 updates JUST because you don't care about proper connection handling? This is very expensive. How do you deal with joins and projects between multiple classes? You force different data contexts (one per class) which will result in a total inability of the underlying provider to optimize - not that it is technically impossible, but I am sure the developer will just tell you to sue the stuff properly when asked why it does not take care of it.

This will require a total rewrite to get into a sensible approach - open a connection when the page starts, close it when the page ends. Well, sometimes more than one if you need separate database transactions, but generally - no.

Plus get one of those beginner books telling you about the repository pattern. We run all db access throuh a DataManager.

DataManager contains connection, implements stuffl like Entity which is IQueryable.Open one at the start, use it as you need, finished.