Зачем в 3-звенке свой ADOConnection для каждого клиента?

← →
AkaSaint (2003-06-10 19:15) [0]

Сабж? В тех примерах, которые я встречал, сделано так. Ведь с базой напрямую не общается ни один клиент, а общаются они с сервером приложений. Почему не сделать 1 ADOConnection на всех? Наверное, я чего-то не понимаю или не знаю, подскажите, пожалуйста.

← →
clickmaker (2003-06-10 20:06) [1]

Каждому клиенту сервер выделяет свой поток. А отдельный поток - отдельный коннект к БД и свой процесс (spid) на SQL сервере. В этом случае будет работать механизм параллельного выполнения транзакций, т.е. для каждого коннекта своя транзакция, вплоть до того, что на многопроцессорных серверах SQL сервер может эти все потоки раскидать по процессорам для ускорения.

← →
Тих (2003-06-10 20:10) [2]

Все верно. Это ценный ресурс. Имеет смысл оборачивать коннекшн в класс с методом GetAdoQuery, что-то навроде
TSingleConnection = class
private
FConnection: TAdoConnection;
public
...
function GetAdoQuery: TAdoQuery;
constructor, destructor...
end;
function TSingleCOnnection.GetAdoQuery;
begin
Result := TAdoQuery.Create(nil);
Result.Connection := FConnection;
...
end;
Ну и не забывать освобождать экземпляры. Можно создавать массив TAdoConnection`ов и как-то разруливать их равномерное использование; возможно, вам повезет и при открытии нового TAdoConnection ядро подсунет вам кэшированное не используемое соединение (т.н. Connection Pooling, который поддерживает и OLE DB, и ODBC)

← →
Shaman_Naydak (2003-06-10 20:24) [3]

> Тих (10.06.03 20:10)
Смысла нет.. по умолчанию, ole db имеет пул соединений.
Так что, если строка соединения все время одна и та же,
то коннектионы зря не тратятся

← →
Тих (2003-06-10 21:04) [4]

пул пулом, но когда вы пишете pConn := TAdoConnection.Create, класс просит CoCreateInstance и получает _Connection; при работе с, например, MS SQL открывается новое соединение по какому-то (1431) порту, eсли мы работаем по TCP/IP.
Несмотря на утверждения MSDN о том, что Connection берется из пула, если прошло меньше минуты, иногда хрен его знает отчего открывалось 2-3-4-5 физическое соединение, а не использовалось существующее из "пула". Проверялось сниффером.

← →
Тих (2003-06-10 21:05) [5]

притом ConnectionString`и, ес-но, одинаковые...

← →
AkaSaint (2003-06-10 21:12) [6]

2clickmaker: понятно, спасибо вам.
2Тих:из ваших слов не понятно, в чем все же выгода (или невыгодность) от использования своих ADOConnection для каждого клиента.
2Shaman_Naydak: а каковы характеристики этого пула (где бы поподробнее про него узнать: как это все организовано изнутри, сколько по умолчанию соединений в пуле, что если затребовано больше соединений, потребление этим всем ресурсов компа и т.д.)? Если строка соединения одна и та же и используется одно соединение, как же тогда происходит управление параллельными транзакциями, запущенными клиентами, соединившимися с использованием одной и той же строки соединения?

← →
Тих (2003-06-10 21:32) [7]

Я как-то давно делал двузвенку, в которой на формы и датамодули по неопытности было накидано около 80 TAdoQuery(в design-time connected=false) и соовт. TAdoConnection(в design-time connected=true). Во время тестирования (десяток экземпляров запущенного приложения, запросы еще _НЕ_ОТКРЫТЫ_) прибежал админ и сообщил, что MS SQL сервер тормозит. Посмотрели трафик - нашли примерно 20 физических соединений на каждый запущенный экземпляр. Переназначил всем AdoQuery единственный коннекшн - проблема исчезла. В чем дело - не знаю. Почитать про пулинг можно в разделе MDAC SDK Technical Articles сайта msdn.microsoft.com, статья "Pooling in the Microsoft Data Access Components". Но там сообщается лишь о том, что клиенут возвращается кэшированный COM-объект. Как пулинг реализуется ФИЗИЧЕСКИ - я не знаю.

← →
Dred2k (2003-06-10 21:51) [8]

http://www.geocities.com/SiliconValley/Campus/3207/Translations/Threading_RUS.html

Очень полезная статья про потоковые модели в 3x.

← →
Dred2k (2003-06-10 21:54) [9]

Да, чуть не забыл.
В D4 (со всеми апдейтами), как не старайся, апартмент сделать невозможно - при создании объекта все для этой схемы указывается, но в реальности - все клиентские подключения отрабатывают в главной нити приложения. Обнаружено с помощью GetCurrentThreadID.
В D6 такой ерунды нет.
Проверялось только на вышеуказанных версиях.

← →
Тих (2003-06-10 22:04) [10]

← →
Dred2k (2003-06-10 22:10) [11]

> Тих (10.06.03 22:04)

Правила и способы использования механизмов доступа напрямую зависят от выбранной потоковой модели COM.

← →
AkaSaint (2003-06-11 17:07) [12]

2Dred2k: спасибо за ссылку, очень полезная вещь, прилично написано, хотя я не все понял :-)

Зачем в 3-звенке свой ADOConnection для каждого клиента? Найти похожие ветки