![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Научите меня быть умным! (.NET) Отсоединенное соединение. [D1]
Курдль © (2004-06-04 09:20:00)...или отключенное подключение :)
На самом деле вопрос очень важный! Ведь при переходе на Delphi 8 и технологию .NET возникает крушение стереотипов!
Видимо придется проститься со старыми принципами подключения к БД. Например, как раньше, - открыть приложение, совершить типа DataBase.Connection.Open, поработать и в конце дня сделать DataBase.Connection.Close - непозволительная роскошь!
Вот и вопрос. Кто может поделиться материалами, ссылками, опытом по созданию проектов .NET в части касающейся работы с Connection-ами?
Polevi (2004-06-08 11:43:00) [1]> [35] Курдль © (08.06.04 09:14)
инициатива .NET ориентирована на интернет
Курдль (2004-06-08 09:14:00) [2]
> Либо - в лучшем случае - Вы просто еще не научились работать
> с Connection`ами, и все не так плохо.
У меня несколько книг + инетовские примеры + визард VS по созданию дата-форм. И везде технология одинакова.
Откуда растут ноги - понятно. MS решил завалить Линукса, прикрыть SUN Java и навредить Ораклу посредством унификации подхода программирования доступа к данным. Естественно, при интернет-коннекте есть смысл отключаться как можно быстрее (т.е. проводить физический дисконнект). Это проецируется и на работу виндоуз-приложений.
Petr V. Abramov (2004-06-08 00:38:00) [3]> по 10 соединений будут открывать
в смысле пересоединяться на каждый чих
Petr V. Abramov (2004-06-08 00:37:00) [4]> все 10 показались на сервере.
> Научите меня быть умным! (.NET)
Ну тогда такую умность скажу:
Либо - в лучшем случае - Вы просто еще не научились работать с Connection`ами, и все не так плохо.
Либо плюньте на это, потому как по 10 соединений будут открывать все программы, не только Ваша :)
> (.NET)
Организованной толпой
Коровы шли на водопой
Попить воды Бу-бу-бу-бу
По-ть с кусты Бу-бу-бу-бум
:)
Курдль (2004-06-07 23:58:00) [5]
> Но если за Connection на самом деле стоят реальные хендлы
> и при открытии/закрытии оно все время логинится/отсоединяется
> - ну тогда фьюююююю - идеологи или грибов плохих поели,
> или не видят другого способа заставить покупать больше процессоров
> и памяти.
Мои наблюдения со стороны сервера показали:
При "Cache Authentication=True" при каждом коннекте из текущего приложения на сервере регистрируется новое соединение с уникальным идентификатором. Ради интереса открывал 10 соединений - все 10 показались на сервере.
При дисконнекте всех соединений одно все равно остается висеть до тех пор, пока не закрывается приложение.
При "Cache Authentication=False" при последнем дисконнекте все соединения тухнут.
Petr V. Abramov (2004-06-07 22:11:00) [6]> Открытый запрос в режиме CashedUpdates на сервере ничего не
> держит
Ну курсор-то все он ж держит, хотя бы потому, что его могли "недофетчить" еще. Но это вопрос реализации. В идеале после выборки последней записи курсор можно было бы спокойно закрывать (на уровне OCI, и, соответственно, на сервере).
Но если за Connection на самом деле стоят реальные хендлы и при открытии/закрытии оно все время логинится/отсоединяется - ну тогда фьюююююю - идеологи или грибов плохих поели, или не видят другого способа заставить покупать больше процессоров и памяти.
Если же Connection просто закрывает курсор - ну тогда очень правильно делает.
Sergey Masloff (2004-06-07 21:34:00) [7]Polevi © (06.06.04 10:25) [29]
Давайте поконкретнее. Что у вас за пользовательские объекты которые что-то там держат. Открытые на сервере курсоры?
Открытый запрос в режиме CashedUpdates на сервере ничего не держит. Да и без этого режима обычно не держит. Повторю - тысячи таких сессий сервер не особенно напрягают.
Да, в трехзвенной архитектуре отсоединенные датасеты имеют смысл, в двухзвенке обычно-нет. Так как усложнение разработки и отладки, медленнее работа а реальных преимуществ - не особо-то видно...
Polevi (2004-06-06 10:25:00) [8]проблема не колве открытх сессий на DB-Serverе, а в колве пользовательских объектов, которые их держат
stateless модель гораздо лучше масштабируется, это не надо доказывать, я надеюсь ?
Polevi (2004-06-06 10:23:00) [9]> [24] Sergey Masloff (04.06.04 22:53)
>я попросил бы привести пару-тройку наглядных реальных примеров того что >отсоединенный рекордсет..
любая >2 звенная архитектура с stateless объектами
Курдль (2004-06-04 23:54:00) [10]
> Fay © (04.06.04 23:21) [26]
> Впервые слышу об этих хорошо известных рекомендациях...
> Мне уже пора на свалку? 8(
Вам тоже NASA не приходилось автоматизировать? :)))
Это у них Оракл на 8000 коннектов работал еще до появления даже фантазий про ADO :)
Fay (2004-06-04 23:21:00) [11]Впервые слышу об этих хорошо известных рекомендациях...
Мне уже пора на свалку? 8(
Sergey Masloff (2004-06-04 22:58:00) [12]Добавлю что работа по технологии отсоединенных данных мне известна не понаслышке, в том числе я реализовал в такой технологии минимум два проекта (без использования ADO - на собственной реализации связки объектной модели с РСУБД) - один эксплуатируется уже порядка шести лет, другой три года (порядка полутора тысяч инсталляций) - и должен сказать что у этой технологии (как и у всех остальных) достаточно как плюсов так и минусов, так что называть всех не придерживающихся такой технологии различными нелестными эпитетами как минимум странно.
Sergey Masloff (2004-06-04 22:53:00) [13]Delirium © (04.06.04 15:16) [16]
>для возможности "отвязаться" от сервера.
Да только не всегда это нужно. В смысле отвязываться. Есть какие-то доводы в пользу этого решения кроме рекомендаций "идеологов Майкрософт"? Вернее, доводы, конечно есть но всегда ли они работают?
В случае локальной сети особого смысла в закрытии коннекта нет. Нагрузку он дает только на момент реального обмена данными, ну так и в случае отсоединенного датасета нужно обмен с базой производить - никуда не дется коннект нужен. Так и чего его дергать туда-сюда? Реальная нагрузка от открытого коннекта ничтожна, даже на Win-платформе Oracle не напрягаясь держит полторы-две тысячи коннектов. Минимизировать обмен данными позволяют и другие технологии, те же кэшированные изменения и так далее. Но при высокой интерактивности приложения и когда большинство действий пользователя связаны с обращениям к серверной бизнес-логике то постоянно открытый коннект может быть весьма удобен.
Так что я попросил бы привести пару-тройку наглядных реальных примеров того что отсоединенный рекордсет это единственное возможное решение на все случаи жизни. Только не надо общих слов и ссылок на рекомендации идеологов - эти рекомендации хорошо известны но не всегда их стоит воспринимать как истину в последней инстанции.
Курдль (2004-06-04 22:01:00) [14]
> Не могу не тыкать клоуну, считающему себя умнее идеологов
> Miicrosoft.
А Вы не идеолог, случаем? Им всегда было очень легко, как например идеологам отечественного автомобилестроения :)
Дело не в идеологах, а в реализаторахот Борланда!
Если, конечно, делать программы - записные книжки или тесты для школы, то можно и не подозревать, зачем у профессиональных датасэтов есть свойство "OnApplyRecord", которого нет у ADO, как и многих других.
Delirium (2004-06-04 16:28:00) [15]Написал бы честно: "Не умею работать с ADO, учиться - лень, взял что попало под руку и стал ваять, а теперь, когда софта наворочал - переходить тяжело", а то - "наиболее профессиональные"! Т.е. типа в состоянии оценить профессианолизм решения, а вот научиться ADO пользоваться по человечески - не можешь.
Delirium (2004-06-04 16:21:00) [16]"Использование ADO было отвергнуто нами пару лет назад, как крайне неудобное и опасное" - ну насмешил :) Не могу не тыкать клоуну, считающему себя умнее идеологов Miicrosoft.
Polevi (2004-06-04 16:04:00) [17]>как крайне неудобное и опасное
можно поподробнее
Курдль (2004-06-04 15:35:00) [18]
> Вы меня не понимаете я вижу, сама связка "DBGrid-DataSource-DataSet-DataBase",
> уже порочна. Нельзя превращать приложение в on-line редактор
> для БД. Так делают лишь для локальных DBF-таблиц, да и то
> редко. Использование ADO в том числе и старого, подразумевает
> толстого клиента, собственно для и этого и придуман 'ADODB.Recordset'
> - для возможности "отвязаться" от сервера.
1. Указанную связку я привел, как наиболее наглядную.
2. Использование ADO было отвергнуто нами пару лет назад, как крайне неудобное и опасное. Надеюсь, что в ADO.NET исправят.
3. Компоненты "Direct Oracle Access" или "SQL Direct" (наиболее профессиональные из всех, что существуют для Delphi) предполагают именно работу с открытым коннектом.
Delirium (2004-06-04 15:24:00) [19]По поводу литературы: http://www.gotdotnet.ru/LearnDotNet/ADONET/default.aspx
читайте, учитесь, не спешите воспринимать свои личные подходы как истину последней инстанции.
Polevi (2004-06-04 15:17:00) [20]> [15] Курдль (04.06.04 15:10)
это зависит от датасета
> и вам советую
>И напрасно!
если вы знаете все лучше всех, зачем задвать вопросы в форуме, учитель ?