OnConnect в TidTCPServer и обращение к базе.

← →
DVM © (2006-11-03 13:26) [0]

Возник вот какой вопрос:

Есть сервер TidTCPServer, принимающий соединения от клиентов. При подключении клиента мне надо в базу MSAccess занести запись о IP адресе и порте клиента и сразу отключить оного. Зачем так надо - неважно. Общение с базой через ADO.

Вопрос в следующем: должен ли я оборачивать в критические секции вызов функции добавления записи в лог в OnConnect сервера? Без критических секций виснет сервер.

т.е. так правильно:

procedure TfrmMain.IdTCPServerConnect(AThread: TIdPeerThread); var Zone: integer; Sensor: integer; State: boolean; begin try cs.Enter; try Log(AThread.Connection.Socket.Binding.PeerIP, ....); finally cs.Leave; end; finally AThread.Connection.Disconnect; end; end;

← →
Сергей М. © (2006-11-03 13:39) [1]

> должен ли

А это не важно. Хоть с КС хоть без нее - логика не верна концептуально.

Каждый доп.трэд должен создавать собственную ADO-коннекцию, ты же пытаешься использовать одну-единственную коннекцию для всех своих тредов.

← →
Reindeer Moss Eater © (2006-11-03 13:42) [2]

Может он хочет что бы клиентские запросы выполнялись на параллельно, а в порядке поступления.

Тогда cs ему поможет

← →
DVM © (2006-11-03 13:43) [3]

> Хоть с КС хоть без нее - логика не верна концептуально.

Да, я потому и спрашиваю, чувствую что не все хорошо в данном коде.
Но с критическими секциями работает нормально ведь.
Да и есть ли смысл так усложнять если надо зафиксировать лишь факт коннекта.
Я где то читал еще что если динамически создавать ADO Connection возникает утечка памяти.

← →
DVM © (2006-11-03 13:44) [4]

> Может он хочет что бы клиентские запросы выполнялись на
> параллельно, а в порядке поступления.

Мне параллельность не нужна, мне надо просто фиксировать факт запроса. Очередность тоже не важна.

← →
Reindeer Moss Eater © (2006-11-03 13:48) [5]

Мне параллельность не нужна, мне надо просто фиксировать факт запроса. Очередность тоже не важна.

Тогда все обращения с бд обернуть входами выходами в/из кс.
Очередной подсоединившийся клиент будет курить пока не освободится секция.

← →
DVM © (2006-11-03 13:50) [6]

Спасибо всем, так и сделаем.

← →
Сергей М. © (2006-11-03 15:55) [7]

Есть метод TThread.Syncronize.

При его грамотном использовании никаких засад с одной коннекцией (открытой, к примеру. в осн.треде) не предвидится.

Самое оно то для задачи автора.

← →
DVM © (2006-11-03 16:18) [8]

> Есть метод TThread.Syncronize.

А там же параметры не передать никак в функцию.

← →
Сергей М. © (2006-11-03 16:34) [9]

> DVM © (03.11.06 16:18) [8]

Это из другой оперы.

← →
DVM © (2006-11-05 10:39) [10]

Сделал через посылку сообщения с указателем на структуру о клиенте из клиентского потока сервера в основной поток. Так удобнее, чем через Synchronize.

← →
Сергей М. © (2006-11-05 16:38) [11]

> Так удобнее, чем через Synchronize.
> <Цитата>

Вот уж глупости

← →
DVM © (2006-11-06 15:18) [12]

> Вот уж глупости

Вот уж не глупости. А вполне логичный и надежный вариант. Synchronize в конце концов тоже шлет сообщение.

Я что-то не представляю себе как в класс TIdPeerThread добавить процедуру, которую бы потом можно было передать в качестве праметра в Synchronize; Плюс передача параметров тоже проблема.

procedure TfrmMain.IdTCPServerConnect(AThread: TIdPeerThread);
begin
Synchronize(???);
end;

С собщением оказалось проще и короче.

Буду благодарен за разъяснения.

← →
Anatoly Podgoretsky © (2006-11-06 15:48) [13]

> DVM (06.11.2006 15:18:12) [12]
Наверноprocedure TfrmMain.X;-- С уважением,Анатолий Подгорецкий "DVM" <dvmuratov@yandex.ru> wrote in message news:1162549584.12@delphimaster.ru... DVM © (06.11.2006 15:18) [12] > Вот уж глупости Вот уж не глупости. А вполне логичный и надежный вариант. Synchronize в конце концов тоже шлет сообщение. Я что-то не представляю себе как в класс TIdPeerThread добавить процедуру, которую бы потом можно было передать в качестве праметра в Synchronize; Плюс передача параметров тоже проблема. procedure TfrmMain.IdTCPServerConnect(AThread: TIdPeerThread); begin Synchronize(???); end; С собщением оказалось проще и короче. Буду благодарен за разъяснения.------=_NextPart_000_0143_01C701B2.A2553C90

> Synchronize в конце концов тоже шлет сообщение

В 7-ке не шлет, там это по-иному организовано.

> не представляю себе как в класс TIdPeerThread добавить процедуру,
> которую бы потом можно было передать в качестве праметра
> в Synchronize; Плюс передача параметров тоже проблема

TPeerThread в этом плане ничем не отличаетсч от любого иного наследника TThread

> Сергей М. © (06.11.06 18:23) [14]

Спасибо, разбираюсь.

Вообще то с этим OnConnect от TidTCPServer в интернете и литературе сплошь и рядом странная ситуация.
OnConnect сервера однозначно выполняется в доп потоке и все пытаются прямо из другого потока обновлять логи, писать в мемо, листбох-ы и прочее. Но ведь так нельзя делать!

Например у того же М. Кэнту в книге есть строки:

procedure TFormServer. IdTCPServer1Connect (AThread: TIdPeerThread);
begin
lbLog.Items.Add. ("Connected from: " +
AThread. Connection.Socket.Binding.PeerIP);
end

Он обновляет список без всяких Synchronize.

> Он обновляет список без всяких Synchronize.

Если ListBox невидим и коннект всего один, то ничего страшного не произойдет.
В противном случае жди глюков, потому что это очевидная плюха автора

> Сергей М. © (07.11.06 08:26) [16]

Причем пример неправильного использования подают сами разработчики Indy.

Вот из примеров Indy:

procedure TServerFrmMain.ServerConnect(AThread: TIdPeerThread); begin .... Protocol.Lines.Add(TimeToStr(Time)+" Connection from ""+NewClient.DNS+"""); end;

Protocol это TMemo, сервер явно не для одного клиента предназначен.

> DVM © (07.11.06 10:06) [17]

Да начхать, кто этот дурной пример подает. Важно ему не следовать в принципе.

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

> Выяснить в каком потоке вызывается обработчик того или иного
> события можно и без анализа исходников.

Ну вот я так и выяснял GetCurrentThreadID

Ну вобщем спасибо всем вопрос закрыт.

OnConnect в TidTCPServer и обращение к базе. Найти похожие ветки