ASP.NET online üzerinden MSSQL veritabanına bağlanmak için çalışırken, iki veya daha fazla kişi aynı anda bağlandığında, aşağıdaki alırsınız:

MCP açık ve kullanılabilen bir Bağlantı gerektirir. Bağlantının geçerli durumu Bağlanıyor.

Site localhost benim sunucuda gayet iyi çalışıyor.

Bu kaba kodudur.

public Promotion retrievePromotion()
{
    int promotionID = 0;
    string promotionTitle = "";
    string promotionUrl = "";
    Promotion promotion = null;
    SqlOpenConnection();
    SqlCommand sql = SqlCommandConnection();

    sql.CommandText = "SELECT TOP 1 PromotionID, PromotionTitle, PromotionURL FROM Promotion";

    SqlDataReader dr = sql.ExecuteReader();
    while (dr.Read())
    {
        promotionID = DB2int(dr["PromotionID"]);
        promotionTitle = DB2string(dr["PromotionTitle"]);
        promotionUrl = DB2string(dr["PromotionURL"]);
        promotion = new Promotion(promotionID, promotionTitle, promotionUrl);
    }
    dr.Dispose();
    sql.Dispose();
    CloseConnection();
    return promotion;
}

Ters giden ne olabilir ve nasıl düzeltirim?

Edit: unutmadan, bu benim bağlantı dizesi ve Bağlantı statik olarak. Bu nedeni olduğuna inanıyorum. Tavsiye lütfen.

public static string conString = ConfigurationManager.ConnectionStrings["dbConnection"].ConnectionString;
public static SqlConnection conn = null;

Üzgünüm sadece yorum ilk başta, ama ben ilanıyla hemen hemen her gün benzer bir açıklama bu yana birçok kişi düşünüyorum bu akıllı saklanması ADO.NET işlevsellik içine bir DB Sınıfı(bana da 10 yıl önce). Çoğunlukla herhangi bir eylem için yeni bir nesne oluşturmak için daha hızlı gibi görünüyor beri statik/paylaşılan nesneleri kullanmaya karar veriyorlar.

Bu fail-güvenlik açısından performans açısından ne de iyi bir fikir değildir.

Bağlantı Havuzu topraklarındaki kaçak avlanmak yok

ADO.NET dahili ADO-NET Connection-Pool:): VERİTABANI için temel Bağlantıları yönetir neden iyi bir nedeni var

Uygulamada, çoğu uygulama sadece birini kullanın ya da bir kaç farklı bağlantılar için yapılandırmaları. Bu uygulama sırasında anlamına gelir yürütme, çoğu aynı bağlantıları tekrar tekrar açılacak ve kapalı. Açılış bağlantıları kullanır maliyetini en aza indirmek için optimizasyon tekniği bağlantı havuzu olarak adlandırılır.

Bağlantı sayısını azaltır havuzu yeni bağlantılar bu açılması gerekir. Bu Dexter fiziksel sahipliğini korur bağlantı. Hayatta aktif bir dizi tutarak bağlantıları yönetir her verilen bağlantı yapılandırma için bağlantılar. Bir kullanıcı ne zaman aramalar bağlantısı Açık, Dexter kullanılabilir arar havuzda bağlantı. Havuza bir bağlantısı var, eğer yeni bir bağlantı açmak yerine çağırana döndürür. O zaman uygulama Dexter için döner bağlantı Kapatın aramalar alınan kapatma yerine etkin bir bağlantı ayarlayın. Bir kez bağlantı üzerinde yeniden hazır havuz iade edilmiş. sonraki Açık ara.

Yani açıkçası neden yaratarak önlemek için,aslında yarattıkları değil mi,açılıp kapanan beri ya da açılış ve kapanış bağlantıları yok. Bu "bağlantı havuzu bağlantı yeniden kullanılabilir olup olmadığını öğrenmek için" bir bayrak. sadece Ama eğer bir bağlantı varsa çok önemli bir bayrak değil, çünkü "kullanmak"(havuz varsayar bağlantısı), yeni bir fiziksel bağlantı VERİTABANI için openend olmalı çok pahalı.

Hayır, performans geliştirme ama tersi kazanıyorsun. Eğer maksimum havuz boyutu belirtilen (100 varsayılan) ulaşılırsa, hatta özel durumlar(çok fazla açık bağlantıları...) olacaktı. Bu sadece performans muazzam bir etki değil, aynı zamanda kötü hatalar için bir kaynak ve Hareketleri kullanmadan) veri-damping alan.

Dahi statik bağlantılar kullanıyorsanız her iş parçacığı için bir kilit bu nesneye erişmeye çalışıyor yaratıyorsun. ASP.NET doğası gereği çoklu bir ortamdır. Var bu yüzden en iyi performans sorunlarına neden olan bu kilitler için büyük bir şans. Aslında er ya da geç(senin gibi . çok farklı durumlar alırsınız ^em>MCP açık ve kullanılabilen bir Bağlantı gerektirir).

Sonuç:

• Bağlantıları veya herhangi bir ADO.NET nesne yeniden yok.
• Onları statik/yapmayın paylaşılan(VB.NET içinde)
• Her zaman oluşturmak, açık(Bağlantı) halinde, kullanımı, yakın ve onları gereken yere onları imha(f.e. bir yöntem)
• using-statement elden ve(Bağlantı) halinde implicitely kapatmak için kullanın

Bu sadece Bağlantıları en farkedilir rağmen) için de geçerli. Her nesne IDisposable uygulama bertaraf(basit using-statement), System.Data.SqlClient ad.

Yukarıdaki tüm kapsüller özel bir DB Sınıfı karşı konuşuyor ve tüm nesneleri yeniden. Bu çöp için yorumladı nedeni budur. Tek sorun bir kaynak.

EditBurada retrievePromotion-yöntem: olası bir uygulama

public Promotion retrievePromotion(int promotionID)
{
    Promotion promo = null;
    var connectionString = System.Configuration.ConfigurationManager.ConnectionStrings["MainConnStr"].ConnectionString;
    using (SqlConnection connection = new SqlConnection(connectionString))
    {
        var queryString = "SELECT PromotionID, PromotionTitle, PromotionURL FROM Promotion WHERE PromotionID=@PromotionID";
        using (var da = new SqlDataAdapter(queryString, connection))
        {
            // you could also use a SqlDataReader instead
            // note that a DataTable does not need to be disposed since it does not implement IDisposable
            var tblPromotion = new DataTable();
            // avoid SQL-Injection
            da.SelectCommand.Parameters.Add("@PromotionID", SqlDbType.Int);
            da.SelectCommand.Parameters["@PromotionID"].Value = promotionID;
            try
            {
                connection.Open();
                da.Fill(tblPromotion);
                if (tblPromotion.Rows.Count != 0)
                {
                    var promoRow = tblPromotion.Rows[0];
                    promo = new Promotion()
                    {
                        promotionID    = promotionID,
                        promotionTitle = promoRow.Field<String>("PromotionTitle"),
                        promotionUrl   = promoRow.Field<String>("PromotionURL")
                    };
                }
            }
            catch (Exception ex)
            {
                // log this exception or throw it up the StackTrace
                // we do not need a finally-block to close the connection since it will be closed implicitely in an using-statement
                throw;
            }
        }
    }
    return promo;
}