Здравствуйте, Аноним, Вы писали:

А>Как бы встает давняя проблема, где хранить open sql connection чтобы ее не создавать на каждый чих.

Это не проблема. Проблемы появятся когда вы не станете так делать.

Здравствуйте, Аноним, Вы писали:

А>На новой работе требуют использования SqlDataAdapter и пр. старья.
Что же в них старого-то? да и требуют, наверное,не без причины

А>И пока к сожалению не повыпендриваться.
А это обязательно?

А>Как бы встает давняя проблема, где хранить open sql connection чтобы ее не создавать на каждый чих. Давным давно написал я библиотеку, которая хранила connection на стеке в общем тоже довольно кривое решение. Есть идея хранить connection в request и закрывать ее (если открыли) на error или на Uload. Экспериментировать нет ни времени ни желания, плиз подскажите нормальное ли это решение или какое другое получше.
Нормальное решение — закрывать соединение сразу как только оно стало ненужным и не хранить его. Тогда оно вернётся в пул соединений и будет оттуда использовано

День добрый
На новой работе требуют использования SqlDataAdapter и пр. старья. И пока к сожалению не повыпендриваться. Как бы встает давняя проблема, где хранить open sql connection чтобы ее не создавать на каждый чих. Давным давно написал я библиотеку, которая хранила connection на стеке в общем тоже довольно кривое решение. Есть идея хранить connection в request и закрывать ее (если открыли) на error или на Uload. Экспериментировать нет ни времени ни желания, плиз подскажите нормальное ли это решение или какое другое получше.

Здравствуйте, vmpire, Вы писали:

V>Здравствуйте, Аноним, Вы писали:

А>>На новой работе требуют использования SqlDataAdapter и пр. старья.
V>Что же в них старого-то? да и требуют, наверное,не без причины

думаю вы не под win nt сидите, хотя если подумать, что в ней старого?

А>>Как бы встает давняя проблема, где хранить open sql connection чтобы ее не создавать на каждый чих. Давным давно написал я библиотеку, которая хранила connection на стеке в общем тоже довольно кривое решение. Есть идея хранить connection в request и закрывать ее (если открыли) на error или на Uload. Экспериментировать нет ни времени ни желания, плиз подскажите нормальное ли это решение или какое другое получше.

V>Нормальное решение — закрывать соединение сразу как только оно стало ненужным и не хранить его. Тогда оно вернётся в пул соединений и будет оттуда использовано

Ну как бы утешать себя, что все будет хорошо, не самое безопасное занятие. Тем более странно слышать подобный совет, если понимаешь, что рано или поздно, понадобятся транзакции, а передавать транзакцию между tier надоедает очень быстро. Поэтому лично я советую, играть в пятнашки с коннекциями только в очень маленьких проектах. Большой проект требует иных решений.

Здравствуйте, Аноним, Вы писали:

А>Ну как бы утешать себя, что все будет хорошо, не самое безопасное занятие. Тем более странно слышать подобный совет, если понимаешь, что рано или поздно, понадобятся транзакции, а передавать транзакцию между tier надоедает очень быстро.

Между tier-ми? Вы точно понимаете значение этого слова?

А>Поэтому лично я советую, играть в пятнашки с коннекциями только в очень маленьких проектах. Большой проект требует иных решений.

Потому тебе и советуют не играть в пятнашки. А когда понадобятся транзакции спокойно прикрутите TransactionScope и все будут довольны.

Здравствуйте, Аноним, Вы писали:

А>>>На новой работе требуют использования SqlDataAdapter и пр. старья.
V>>Что же в них старого-то? да и требуют, наверное,не без причины
А>думаю вы не под win nt сидите, хотя если подумать, что в ней старого?
Именно под WinNT. Версии 6.1

А>>>Как бы встает давняя проблема, где хранить open sql connection чтобы ее не создавать на каждый чих. Давным давно написал я библиотеку, которая хранила connection на стеке в общем тоже довольно кривое решение. Есть идея хранить connection в request и закрывать ее (если открыли) на error или на Uload. Экспериментировать нет ни времени ни желания, плиз подскажите нормальное ли это решение или какое другое получше.

V>>Нормальное решение — закрывать соединение сразу как только оно стало ненужным и не хранить его. Тогда оно вернётся в пул соединений и будет оттуда использовано

А>Ну как бы утешать себя, что все будет хорошо, не самое безопасное занятие.
Это официально рекомендованный MS способ работы для достижения максимальной производительности. Может, это вас утешит.

А>Тем более странно слышать подобный совет, если понимаешь, что рано или поздно, понадобятся транзакции, а передавать транзакцию между tier надоедает очень быстро. Поэтому лично я советую, играть в пятнашки с коннекциями только в очень маленьких проектах. Большой проект требует иных решений.
Как уже ответил Lloyd, для этого есть TransactionScope.

L>прикрутите TransactionScope и все будут довольны.
если распределенные транзакции не начнутся %) Насколько я помню, запросы к разным датасорсам в одном транзакшен скопе автоматом элевейтят транзакцию до распределенной.

Здравствуйте, Lloyd, Вы писали:

L>Потому тебе и советуют не играть в пятнашки. А когда понадобятся транзакции спокойно прикрутите TransactionScope и все будут довольны.

Увы transaction scope нынче совсем не тот, что был раньше. Я уже наступил на эти грабли.

Здравствуйте, Аноним, Вы писали:

L>>Потому тебе и советуют не играть в пятнашки. А когда понадобятся транзакции спокойно прикрутите TransactionScope и все будут довольны.

А>Увы transaction scope нынче совсем не тот, что был раньше. Я уже наступил на эти грабли.

А что с ним не так?

Здравствуйте, vmpire, Вы писали:

V>Это официально рекомендованный MS способ работы для достижения максимальной производительности. Может, это вас утешит.

Если не трудно дайте плиз прувлинк, я о такой рекомендации слышу впервые в жизни и честно говоря считаю такую рекомендацию невозможной, но все бывает.

Здравствуйте, Synapse, Вы писали:

L>>прикрутите TransactionScope и все будут довольны.
S>если распределенные транзакции не начнутся %) Насколько я помню, запросы к разным датасорсам в одном транзакшен скопе автоматом элевейтят транзакцию до распределенной.

Так и есть.

Здравствуйте, Аноним, Вы писали:

V>>Это официально рекомендованный MS способ работы для достижения максимальной производительности. Может, это вас утешит.
А>Если не трудно дайте плиз прувлинк, я о такой рекомендации слышу впервые в жизни и честно говоря считаю такую рекомендацию невозможной, но все бывает.
http://msdn.microsoft.com/en-us/library/ff647768.aspx#scalenetchapt12_topic9 (поищите "Open and Close the Connection in the Method" в пункте Connections)
http://msdn.microsoft.com/en-us/library/ff647694.aspx

Здравствуйте, vmpire, Вы писали:

Спасибо большое, век живи, век учись.

Здравствуйте, Lloyd, Вы писали:

L>А что с ним не так?

Подымает com+, который я так и не смог сходу настроить.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Lloyd, Вы писали:

L>>А что с ним не так?

А>Подымает com+, который я так и не смог сходу настроить.

Надо, чтобы app server и db server были либо в одном домене, либо в одной подсети. Тогда DTC заработает. Но это содомия и ад, конечно.

Здравствуйте, Synapse, Вы писали:

А>>Подымает com+, который я так и не смог сходу настроить.

S>Надо, чтобы app server и db server были либо в одном домене, либо в одной подсети. Тогда DTC заработает. Но это содомия и ад, конечно.

С другим доменом работает.

Здравствуйте, Аноним, Вы писали:

L>>А что с ним не так?

А>Подымает com+, который я так и не смог сходу настроить.

Т.е. проблема все-таки не с ним?

Здравствуйте, Lloyd, Вы писали:

L>Т.е. проблема все-таки не с ним?

Т.е. превращение обычной транзакции в распределенную это таки не проблема?

Здравствуйте, Аноним, Вы писали:

L>>Т.е. проблема все-таки не с ним?

А>Т.е. превращение обычной транзакции в распределенную это таки не проблема?

Мне показалось, что проблема в следующем:

который я так и не смог сходу настроить.

Разве нет? А являеттся ли распреденная транзакция проблемой ил нет, зависит прежде всего от требований, о которых ничего сказано не было. Вполне может быть и проблемой.