Подводные камни вызова статического метода из ASMX - PullRequest
Новая
       32

Подводные камни вызова статического метода из ASMX

2 голосов
/ 23 августа 2009

Я хотел бы знать, есть ли какие-либо ловушки при вызове статического метода из веб-службы ASP.NET. 

    internal static object SelectScalar(String commandText, DataBaseEnum dataBase)
    {
        SqlConnection sqlc = new SqlConnection(AuthDbConnection.GetDatabaseConnectionString());
        object returnval=null;
        if (sqlc!=null)
        {
            SqlCommand sqlcmd = sqlc.CreateCommand();
            sqlcmd.CommandText = commandText;
            sqlc.Open();
            returnval = sqlcmd.ExecuteScalar();
        }
        return returnval;
    }

Итак, для примера выше метод; Есть ли подводные камни для нескольких веб-методов и нескольких клиентов, вызывающих этот метод одновременно (скажем, 1000 вызовов веб-метода, который вызывает эту функцию)?

Ответы [ 3 ]

3 голосов
/ 23 августа 2009

Я не знаю, является ли C # похожим на Java, но открытие соединения SQL и невозможность закрыть его перед выходом из метода не кажутся мне хорошей идеей. GC очистит его, как только он выйдет из области видимости, но это не то же самое, что закрытие соединения в Java.

Идиома в Java требует, чтобы вы закрывали соединение в блоке finally. Если вы не уверены, что класс C # не требует такой вещи, я бы изучил это.

Скоро вы узнаете - тысячи сетевых звонков быстро исчерпают количество доступных соединений, если их мало.

Еще одна вещь, которую нужно проверить: открытие соединений таким способом дорого в Java, поэтому они обычно объединяются. Пул соединений также выполняется в C #? Неэффективно ли продолжать открывать и закрывать соединение с базой данных? Не могли бы вы сделать то же самое с помощью статического общего соединения? Если вы пойдете по этому пути, возможно, возникнут проблемы с потоками.

3 голосов
/ 23 августа 2009

Поскольку вы создаете новый SqlConnection, вы хотите утилизировать его, иначе соединение не закроется. См. MSDN для инструкций по использованию.

Тот факт, что это статический метод, хотя ... это не проблема, поскольку вы не обновляете никакое общее состояние (глобальные переменные).

РЕДАКТИРОВАТЬ: AFAIK, «подводные камни» статических методов в веб-сервисах такие же, как и в любом другом приложении. Единственное, на что следует обратить внимание, это то, что веб-сервис - это сервер, который, как ожидается, будет надежно работать в течение длительного периода времени. Таким образом, вещи, которые могут вызвать проблемы с течением времени (утечки памяти, истощение соединения с БД и т. Д.), Более значительны, чем для других приложений, которые работают в течение гораздо более короткого периода времени.

3 голосов
/ 23 августа 2009

Следует помнить, что статические члены изменяют состояние, доступное для других потоков в домене приложения. В этих случаях вы должны принять надлежащие меры, чтобы это произошло упорядоченным образом.

Ваш метод не затрагивает ни одно состояние само по себе (все локально), так что все в порядке.

Как отметили Даффимо и Нейдер, вы должны распоряжаться своим соединением так же, как вам следует дозировать любой объект, реализующий IDisposable.

...