ExecuteReader изисква отворена и достъпна връзка. Текущото състояние на връзката е Свързване

Съжалявам, че коментирам само на първо място, но публикувам почти всеки ден подобен коментар, тъй като много хора смятат, че би било умно да се капсулира функционалността на ADO.NET в DB-Class (аз също преди 10 години). Най-често те решават да използват статични/споделени обекти, тъй като изглежда, че е по-бързо от създаването на нов обект за каквото и да е действие.

Това не е нито добра идея по отношение на производителността, нито по отношение на безопасността при отказ.

Не ловете на територията на Connection-Pool

Има добра причина, поради която ADO.NET вътрешно управлява основните връзки към СУБД в ADO -NET Connection-Pool:

На практика повечето приложения използват само една или няколко различни конфигурации за връзки. Това означава, че по време на изпълнение на приложението много идентични връзки ще бъдат многократно отваряни и затваряни. За да минимизира разходите за отваряне на връзки, ADO.NET използва техника за оптимизация, наречена групиране на връзки.

Пулирането на връзки намалява броя на отварянето на нови връзки. Пулърът поддържа собствеността върху физическата връзка. Той управлява връзките, като поддържа набор от активни връзки за всяка дадена конфигурация на връзка. Всеки път, когато потребител извика Отваряне на връзка, пулерът търси налична връзка в пула. Ако е налична обединена връзка, тя я връща на повикващия, вместо да отваря нова връзка. Когато приложението извика Close на връзката, пулът я връща към обединения набор от активни връзки, вместо да я затваря. След като връзката бъде върната към пула, тя е готова за повторно използване при следващото отворено повикване.

Така че очевидно няма причина да избягвате създаването, отварянето или затварянето на връзки, тъй като всъщност те изобщо не се създават, отварят и затварят. Това е "само" флаг за пула на връзките, за да знае кога връзката може да се използва повторно или не. Но това е много важен флаг, защото ако връзката е "в употреба" (пулът на връзките предполага), новата физическа връзка трябва да бъде отворена към СУБД, което е много скъпо.

Така че не получавате подобрение на производителността, а точно обратното. Ако определеният максимален размер на пула (100 е по подразбиране) бъде достигнат, дори ще получите изключения (твърде много отворени връзки ...). Така че това не само ще повлияе изключително много на производителността, но също така ще бъде източник на неприятни грешки и (без използване на транзакции) област за изхвърляне на данни.

Ако дори използвате статични връзки, вие създавате заключване за всяка нишка, опитваща се да получи достъп до този обект. ASP.NET е многонишкова среда по природа. Така че има голям шанс за тези ключалки, което в най-добрия случай причинява проблеми с производителността. Всъщност рано или късно ще получите много различни изключения (като вашият ExecuteReader изисква отворена и достъпна връзка).

Заключение:

• Не използвайте повторно връзки или изобщо ADO.NET обекти.
• Не ги правете статични/споделени (във VB.NET)
• Винаги създавайте, отваряйте (в случай на връзки), използвайте, затваряйте и ги изхвърляйте, където имате нужда от тях (напр. в метод)
• използвайте using-statement за изхвърляне и затваряне (в случай на връзки) имплицитно

Това е вярно не само за Connections (макар и най-забележимо). Всеки обект, изпълняващ IDisposable, трябва да бъде унищожен (най-просто чрез using-statement), още повече в пространството от имена System.Data.SqlClient.

Всичко по-горе говори против персонализиран DB-клас, който капсулира и използва повторно всички обекти. Това е причината, поради която коментирах, за да го изхвърля на боклук. Това е само проблемен източник.

Редактиране: Ето възможно внедряване на вашия retrievePromotion-метод:

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(); // not necessarily needed in this case because DataAdapter.Fill does it otherwise 
                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;
}

Хванах тази грешка преди няколко дни.

В моя случай това беше, защото използвах транзакция на Singleton.

.Net не работи добре със Singleton, както е посочено по-горе.

Моето решение беше следното:

public class DbHelper : DbHelperCore
{
    public DbHelper()
    {
        Connection = null;
        Transaction = null;
    }

    public static DbHelper instance
    {
        get
        {
            if (HttpContext.Current is null)
                return new DbHelper();
            else if (HttpContext.Current.Items["dbh"] == null)
                HttpContext.Current.Items["dbh"] = new DbHelper();

            return (DbHelper)HttpContext.Current.Items["dbh"];
        }
    }

    public override void BeginTransaction()
    {
        Connection = new SqlConnection(Entity.Connection.getCon);
        if (Connection.State == System.Data.ConnectionState.Closed)
            Connection.Open();
        Transaction = Connection.BeginTransaction();
    }
}

Използвах HttpContext.Current.Items за моя екземпляр. Този клас DbHelper и DbHelperCore е мой собствен клас