Умеет ли поддерживать связь в течение всего сеанса? Я сделал приложение C#, которое подключается к базе данных MySql, программа читает и записывает на нее, и приложение должно работать около 10 часов в день без остановок.Соединение MySql, могу ли я оставить его открытым?
Есть ли риск, связанный с открытием соединения, вместо вызова функции close() каждый раз после того, как вы вырвали что-то из базы данных и снова открыли, когда вам нужно что-то новое?
Оставляя соединение открытым на некоторое время, это хорошо, до тех пор, как:
вы не так много одновременно неактивных соединений, которые вы превысите предел соединения MySQL;
не оставляйте его открытым для часов без каких-либо действий. Соединение MySQL по умолчанию wait_timeout составляет 8 часов; оставьте соединение неактивным в течение этого времени, и когда вы приступите к его использованию, вы получите сообщение об ошибке «Сервер MySQL ушел».
Если приложение использует соединение, нет причин закрывать его. Если вам не требуется соединение, вы должны закрыть его. Если вам нужно подключить несколько приложений к базе данных, у вас есть фиксированное количество подключений к этой базе данных. Вот почему лучше закрыть, когда вы закончите, и снова открыть, когда вам это нужно.
С точки зрения безопасности, я бы сказал, что лучше, чтобы закрыть его после запроса, просто чтобы быть уверенным, что никакая другая программа не может вводить свои собственные вещи в открытое соединение.
Поскольку производительность конусообразна, очевидно, что лучше всего открыть соединение в течение всего времени.
Ваш выбор ^^
Поскольку вы используете ADO.NET, вы можете использовать встроенные соединение ADO.NET в пулы возможности. На самом деле, позвольте мне уточнить это: вы должны всегда использовать встроенные возможности объединения ADO.NET. Поступая таким образом, вы получите среду выполнения .NET, чтобы прозрачно управлять своими подключениями для вас в фоновом режиме. Он будет держать соединения открытыми на некоторое время, даже если вы их закрыли и повторно их используете, если вы откроете новое соединение. Это очень быстро.
Обязательно укажите в строке подключения, что вы хотите объединить соединения, поскольку это может быть не поведение по умолчанию.
Вам только нужно создать соединения локально, когда вы нуждаетесь в них, так как они объединяют в backrgound так что нет никаких накладных расходов при создании нового соединения:
using (var connection = SomeMethodThatCreatesAConnectionObject())
{
// do your stuff here
connection.Close(); // this is not necessary as
// Dispose() closes it anyway
// but still nice to do.
}
Вот как вы должны сделать это в .NET.
Нет, я не вижу причин, по которым нельзя оставлять соединение открытым и повторно использовать его: в конце концов, это все, что связано с различными технологиями пула соединений (хотя они обычно зарезервированы для многопоточных ситуаций, когда все работы работают на одном источнике данных).
Но, чтобы расширить ответ на bobince, - просто потому, что вы не закрываете соединение, не предполагайте, что что-то еще не будет: подключение может затянуться, могут возникнуть проблемы с подключением или сто один другие причины, по которым ваша связь умирает. Вы должны предположить, что соединение может быть не там, и добавить логику в код для этого случая исключения.
Неплохая практика, на мой взгляд, поддерживать открытые соединения. Другим аспектом, который каждый раз говорит о закрытии соединений, является масштабируемость. Теперь может быть неплохо оставить его открытым, но что делать, если приложение используется дважды в 3 раза больше пользователей. Это боль в шее, чтобы вернуться и изменить весь код. (я знаю, что сделал это :-)
Ваша проблема будет решена, если вы используете пул соединений в своем коде. Вам не нужно открывать и закрывать соединение, поэтому вы сохраняете драгоценные ресурсы, которые используются при открытии соединения. Вы просто возвращаете соединение в пул, который при запросе на соединение возвращает обратно незанятое соединение.
Конечно, я придерживаюсь мнения, получаю экземпляр подключения, использую его, совершаю/откатываю вашу работу и возвращаю ее в пул. Я бы не советовал держать связь открытой так долго.
В других ответах я еще не видел. В случае, если вы подготовили операторы или временные таблицы, они могут блокировать ресурсы сервера до закрытия соединения. Но, с другой стороны, может быть полезно поддерживать связь в течение некоторого времени, а не воссоздавать их каждые несколько мгновений.
Вы будете платить штраф за выполнение, если вы постоянно открываете и закрываете соединения. Возможно, было бы разумно использовать пул соединений и короткий wait_timeout, если вы обеспокоены тем, что слишком много работающих копий вашего приложения будут потреблять слишком много соединений с базой данных.
Это не тот случай, это единственное приложение, которое работает, и ничто другое не должно пытаться подключиться. – Pieter888
Нет причин, по которым я когда-либо слышал о том, что вы хотели бы разорвать соединение в этом случае. Если ваше приложение может автоматически и прозрачно восстановить соединение, то оно не предлагает вам никакой дополнительной безопасности (на самом деле вы теряете некоторые из-за того, что каждая аутентификация предоставляет крошечный бит информации). На самом деле популярная встроенная функция, называемая пулом соединений, приводит к тому, что соединения остаются открытыми, даже когда вы сообщаете код, чтобы закрыть его, чтобы соединение можно было повторно использовать другим процессом без накладных расходов на аутентификацию. – MightyE
Таким образом, соединение будет автоматически восстановлено, когда соединение будет открыто *? Или мне нужно написать свой собственный код, чтобы обнаружить это? – Pieter888
Да, можно, при условии:
В основном это требует большого внимания к случаям отказа и правильному восстановлению; подключение и отключение часто намного проще.
Я думаю, что если есть механизм объединения соединений, лучше закрыть соединение.
Одна из причин этого заключается в том, что вам не нужно повторно проверять, жив ли ваш контакт или нет.
Нет ничего, что можно было бы получить, поддерживая соединение открытым (предполагая, что поставщик использует пул соединений). Официальный поставщик MySQL Connector/Net использует пул соединений по умолчанию. В OP не упоминается, какой провайдер они фактически используют, но если он поддерживает объединение, я бы использовал открытую раннюю стратегию позднего/закрытого периода и позволял провайдеру управлять базовыми физическими соединениями. – LukeH
Извините, что добавил комментарий к старой теме. Я читаю http://download.oracle.com/javadb/10.3.3.0/devguide/cdevconcepts89498.html, кажется, что до тех пор, пока ваше приложение имеет несколько потоков/транзакций, рекомендуется назначить каждый поток отдельному соединению , Благодарю. –