Sql соединение в службе Windows - PullRequest
Новая
       31

Sql соединение в службе Windows

0 голосов
/ 29 марта 2011

Я написал службу Windows, которая прослушивает данные от сторонних служб, на короткое время удерживает их в памяти и периодически все новые данные сбрасываются в базу данных.

Первоначально я открывал новое соединение каждый раз, когда мне нужно было сбросить данные, и затем снова закрывать его. (Каждые 5 секунд или около того)

Поскольку сервер, кажется, забивается, я изменил его, так что теперь существует одно открытое соединение, которое используется повторно для жизни приложения.

Просто интересно, если это плохая идея?

Я обычно занимаюсь веб-вещанием, где соединение открыто и закрыто в течение срока действия одного запроса. Какова наилучшая практика для службы Windows, которая должна выполнять описанную мной операцию?

Я собирался установить отказоустойчивое соединение, как это: 

private SqlConnection _sqlConnection;
public SqlConnection SqlConnection
{
    get
    {
        if (_sqlConnection == null || !_sqlConnection.State.Equals(ConnectionState.Open))
        {
            var conn = new SqlConnection(_connectionString);
            conn.Open();
            return conn;
        }

        return _sqlConnection;
    }
}

поэтому, если по какой-либо причине существующее соединение будет закрыто или каким-либо образом повреждено, мы получим новое открытое

это плохой дизайн по какой-либо причине?

Ответы [ 3 ]

1 голос
/ 29 марта 2011

Используйте здравый смысл.Если вы являетесь единственным пользователем базы данных, удерживайте соединение.Если нет, то вы действительно можете рассчитывать на пул соединений, чтобы сделать это для вас.

Лично я бы пошел на открытие соединения каждый раз.В .NET 2.0 была реализована новая функция, так что если у вас есть открытое соединение с сервером sql и сервер sql перезапускается и т. Д. ... ваше соединение становится недействительным, и я не могу рисковать своим сервисом. См. мой пост т несколько лет назад.

1 голос
/ 29 марта 2011

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

0 голосов
/ 29 марта 2011

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

Я рекомендую более распространенную схему использования соединения: открывать, использовать, закрывать / утилизировать. Код будет намного легче писать и поддерживать. Убедитесь, что вы избавляетесь от всех объектов команд и соединений, как только закончите с ними. Контролируйте свое приложение с помощью инструмента профилирования и проверяйте количество открытых соединений с базой данных на сервере, чтобы убедиться, что ваш код работает так, как вы планировали.

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

Если ваши данные ценны, вы можете рассмотреть возможность использования двух процессов. Один процесс вызывает веб-сервис и надежно сохраняет полученные данные в очереди сообщений. Другой процесс читает сообщения из очереди и помещает данные в сообщение в базу данных.

Этот способ обработки этого процесса означает, что вы можете получать данные, пока база данных временно не работает, и все данные в конечном итоге будут храниться в базе данных.

Несмотря на то, что это надежное решение, его также легко считать излишним, в зависимости от ваших требований.

...