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

Question

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

2

Я хотел бы знать, есть ли какие-либо подводные камни при вызове статического метода из веб-службы 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 вызовов веб-метода, который вызывает эту функцию)?

choudeshell 23 авг. 2009, в 20:51

Источник

Теги:

c#

asp.net

.net

static

asmx

3 ответа

3

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

Идиома в Java потребует закрыть соединение в блоке finally. Если вы не уверены, что класс С# не требует такого, я бы посмотрел на него.

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

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

duffymo 23 авг. 2009, в 17:34

0

Вам пишут о необходимости вызова утилизировать на связи. +1 для вас.
Alfred Myers 23 авг. 2009, в 18:39
0

@duffymo: Да, пул может. См. Msdn.microsoft.com/en-us/library/8xx3tyca(VS.71).aspx
Nader Shirazie 23 авг. 2009, в 18:43
0

Извините, я только что скопировал этот небольшой фрагмент и отредактировал его. Да, мы закрываем соединение и используем пул соединений. Мне просто интересно, есть ли там какие-нибудь подводные камни - не совсем уверен, какой тип или тип подводных камней. Мы используем этот тип парадигмы во многих местах.
choudeshell 23 авг. 2009, в 18:50

Показать ещё 1 комментарий

3

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

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

Как отмечают duffymo и nader, вы должны избавиться от своего соединения, поскольку вы должны дипостировать любой объект, который реализует IDisposable.

Alfred Myers 23 авг. 2009, в 15:52

Ещё вопросы

Вам пишут о необходимости вызова утилизировать на связи. +1 для вас.
@duffymo: Да, пул может. См. Msdn.microsoft.com/en-us/library/8xx3tyca(VS.71).aspx
Извините, я только что скопировал этот небольшой фрагмент и отредактировал его. Да, мы закрываем соединение и используем пул соединений. Мне просто интересно, есть ли там какие-нибудь подводные камни - не совсем уверен, какой тип или тип подводных камней. Мы используем этот тип парадигмы во многих местах.

Nader Shirazie · Accepted Answer · 2009-08-23T17-32-00.000Z

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

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

EDIT: AFAIK, "ловушки" статических методов в веб-сервисах такие же, как и в любом другом приложении. Единственное, что следует помнить, это то, что вебсервис - это сервер, который, как ожидается, будет надежно работать в течение длительного периода времени. Таким образом, вещи, которые могут вызвать проблемы с течением времени (утечки памяти, исчерпание связи db и т.д.), Более значительны, чем для других приложений, которые работают в течение гораздо более короткого периода времени.

Да ... Я должен был взглянуть на другие аспекты кода, кроме того, что он потокобезопасен. +1 для вас.
Я только что отредактировал этот маленький фрагмент. Мы закрываем связь.