Если не затруднит многоуважаемых магистров .NET ответить начинающему...
Что значит "отсоединенный доступ"? Означает ли это, что Connection надо закрывать насильственно после каждого сеанса "запрос/НД"? Или система сама позаботится о прерывании связи после приема НД? Если первое, то следует ли вообще иметь какой-нибудь "централизованный" компонент подключения к БД, или лепить на каждой форме свой?
Я не могу сломить стереотипы и отказаться от испытанной стратегии работы приложения, использующего БД:
1. Открываешь главную форму.
2. Позволяешь юзеру вызвать окно логина.
3. При корректном логине открываешь соединение.
4. Во всех формах приложения используешь это соединение (DataBase/Session/Connection и т.п.) для доступа к БД.
5. После работы отключаешь соединение.
Какие противопоказания и рекомендации по переходу к новой счастливой жизни с .NET?
Re: Есть стандарты или хотя бы рекомендации по oleDbConnecti
К>4. Во всех формах приложения используешь это соединение (DataBase/Session/Connection и т.п.) для доступа к БД. К>5. После работы отключаешь соединение.
Говорят, что в .NET соединения (в том числе OleDb и SqlClient) кешируются.
В результате, если ты много раз будешь отключаться-переподключаться, физически оно может и не "менять коней на переправе", так на одном соединении и работать физически.
Во всяком случае, лично я просто всегда использую using или try/finally — и соединения чистоплотно закрываю.
... << RSDN@Home 1.1.3 stable >>
Re[2]: Есть стандарты или хотя бы рекомендации по oleDbConne
M>Говорят, что в .NET соединения (в том числе OleDb и SqlClient) кешируются. M>В результате, если ты много раз будешь отключаться-переподключаться, физически оно может и не "менять коней на переправе", так на одном соединении и работать физически.
В общем-то поэтому мой вопрос и возник. ОДНАКО
Скорее всего мне не хватает знаний, чтобы это реализовать.
При проверке на СУБД Sybase ASA 8 и Oracle 9 каждое новое подключение из одного приложения вызывает открытие новой сессии.
Это, естественно, вызывает нарушения в привычной для меня логике программ — особенно в части касающейся транзакций.
M>Во всяком случае, лично я просто всегда использую using или try/finally — и соединения чистоплотно закрываю.
Мне тоже приходится так же работать. Однако, это весьма не удобно — надо либо каждой форме, работающей с соединениями, передавать в конструкторе соединение (а для этого перекрывать конструктор), либо писать статические методы для получения соединения в отдельном модуле.
Re[3]: Есть стандарты или хотя бы рекомендации по oleDbConne
Здравствуйте, Курдль, Вы писали:
M>>Говорят, что в .NET соединения (в том числе OleDb и SqlClient) кешируются. M>>В результате, если ты много раз будешь отключаться-переподключаться, физически оно может и не "менять коней на переправе", так на одном соединении и работать физически.
К>В общем-то поэтому мой вопрос и возник. К>ОДНАКО К>Скорее всего мне не хватает знаний, чтобы это реализовать. К>При проверке на СУБД Sybase ASA 8 и Oracle 9 каждое новое подключение из одного приложения вызывает открытие новой сессии. К>Это, естественно, вызывает нарушения в привычной для меня логике программ — особенно в части касающейся транзакций.
M>>Во всяком случае, лично я просто всегда использую using или try/finally — и соединения чистоплотно закрываю. К>Мне тоже приходится так же работать. Однако, это весьма не удобно — надо либо каждой форме, работающей с соединениями, передавать в конструкторе соединение (а для этого перекрывать конструктор), либо писать статические методы для получения соединения в отдельном модуле.
Вобщем-то, жестких ограничений тут нет. Работай, как тебе нравится. Можешь открыть коннект в главной форме и передавать в остальные переменную типа OleDbConnection. Только позаботься о том, чтобы при аварийном завершении программы у тебя не осталось открытого коннекта. А .NET без твоего ведома закрывать коннект не будет, если переменная OleDbConnection будет существовать.
Просто, почему-то, считается правилом хорошего тона открывать и закрывать коннект при каждой серии обращений к базе. У обоих подходов есть свои преимущества и недостатки. Но стандартов, как я уже сказал, нет. Для меня этот момент тоже в первый раз вызвал состояние, близкое к шоку, когда я отошел от чистого PL/SQL и начал писать на других языках.
Re: Есть стандарты или хотя бы рекомендации по oleDbConnecti
Здравствуйте, Курдль, Вы писали:
К>Если не затруднит многоуважаемых магистров .NET ответить начинающему... К>Что значит "отсоединенный доступ"? Означает ли это, что Connection надо закрывать насильственно после каждого сеанса "запрос/НД"? Или система сама позаботится о прерывании связи после приема НД? Если первое, то следует ли вообще иметь какой-нибудь "централизованный" компонент подключения к БД, или лепить на каждой форме свой? К>Я не могу сломить стереотипы и отказаться от испытанной стратегии работы приложения, использующего БД: К>1. Открываешь главную форму. К>2. Позволяешь юзеру вызвать окно логина. К>3. При корректном логине открываешь соединение. К>4. Во всех формах приложения используешь это соединение (DataBase/Session/Connection и т.п.) для доступа к БД. К>5. После работы отключаешь соединение.
К>Какие противопоказания и рекомендации по переходу к новой счастливой жизни с .NET?
Во всех нормальных технологиях доступа к данным есть понятие пула соединений. Рекомендуется как ра НЕ делать так как ты делал раньше. Соединение с БД — это ценный ресурс и его надо освобождать как можно раньше. И открывать всякий раз когда необходимо сделать запрос. Если ты будешь делать запросы часто, то соединение будет всегда браться само из пула. Если нет — то и нечего его держать Оно будет создаваться. Теперь самое приятное. Для поддержки пула ничего делать не нужно. И для Sql и Oracle провайдеров пул включен по умолчанию.
Таким образом сценарий теперь выглядит так:
1. Открываешь главную форму.
2. Позволяешь юзеру вызвать окно логина.
3. При корректном логине сохраняешь строку подключения в одном из static полей какого либо обьекта (Connection String).
4. Во всех формах приложения используешь эту строку подключения, каждый раз создавая Connection заново
5. Закрываешь соединение сразу после необходимого запроса.
... << RSDN@Home 1.1.0 stable >>
Народная мудрось
всем все никому ничего(с).
Re[2]: Есть стандарты или хотя бы рекомендации по oleDbConne
Tom>5. Закрываешь соединение сразу после необходимого запроса.
1. Я наблюдал со стороны серверов, что Connection.Close() не вызывает физического прерывания сессии.
2. Как разъяснить транзакции, если возникла сложная взаимосвязанная цепочка обновлений из разных модулей, что она охватывает всю эту цепочку?
Re[3]: Есть стандарты или хотя бы рекомендации по oleDbConne
Tom>>5. Закрываешь соединение сразу после необходимого запроса. К>1. Я наблюдал со стороны серверов, что Connection.Close() не вызывает физического прерывания сессии.
Это и есть проявление пула. Соединение специально не разрывается. Оно будет жить ещё на протяжении некоторого времени.
К>2. Как разъяснить транзакции, если возникла сложная взаимосвязанная цепочка обновлений из разных модулей, что она охватывает всю эту цепочку?
Транзакции нужно передавать соединение.
... << RSDN@Home 1.1.0 stable >>
Народная мудрось
всем все никому ничего(с).
Re[4]: Есть стандарты или хотя бы рекомендации по oleDbConne
Здравствуйте, Tom, Вы писали: Tom>Это и есть проявление пула. Соединение специально не разрывается. Оно будет жить ещё на протяжении некоторого времени.
Если в строке подключения прописать Cache Authentication=False; — оно отваливается по команде.
К>>2. Как разъяснить транзакции, если возникла сложная взаимосвязанная цепочка обновлений из разных модулей, что она охватывает всю эту цепочку? Tom>Транзакции нужно передавать соединение.
Дело в том, что в некоторых проектах приходится поддерживать сложные взаимосвязи между объектами (формами).
Например, одно окно запускает транзакцию, производит обновление, передает управление другому, которое тоже производит изменения и закрывает транзакцию в случае успеха. Видимо теперь придется отказаться от таких конструкций.
Спасибо за ответы! Но я был бы совершенно счастлив и безмерно благодарен за указание первоисточников (как сетевых, так и книжных). А то литературы полно, но вся она поверхтностная и повторяет друг друга... в профиль
