![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Правильно ли круглосточно поддерживать соединение к БД? [D6, MSSQL]
Calm © (2003-11-26 16:03:00)
Уважаемые мастера,
имеется прога, которая читает данные с девайса, подключенная к COM-порту. Данные обрабатываются и пишутся в БД.
Инфа приходит с девайса в среднем не чаще, чем раз в 2 секунды. Этого вполне достаточно для того, чтобы открыть соединение, обработать и записать данные в БД вполне достаточно.
Но предметная область такова, что девай может геренить инфу и 3 раза в секунду. И тут уже может быть критичным время установки соединения. Или я ошибаюсь?
Сейчас тестирую прогу и переодически соединение обрывается. Причину пока не установил, вполне возможно, что глюки у меня.
Но вот захотелось оточнить сабж :)
me (2003-11-26 23:41:00) [1]
> Vlad © (26.11.03 17:44) [20]
MSDN: ADO connection pooling
Johnmen (2003-11-26 17:51:00) [2]
>Vlad © (26.11.03 17:05)
Да, отдельный кон-т в отд.потоке не годиться...
А в другом варианте - проблема с асинхронной проверкой кон-та. Таймер использовать нельзя.
>me (26.11.03 17:36)
Это понятно. И, видимо, над этим стоит подумать...
>Vlad © (26.11.03 17:05)
>me (26.11.03 17:36)
Спасибо за участие.
Vlad (2003-11-26 17:44:00) [3]
> me (26.11.03 17:36) [19]
Сдается мне ты что-то с трехзвенкой путаешь.
Пул коннектов создает COM+ приложение и действительно не закрывает сессию как таковую. А сервер БД тут причем ?
me (2003-11-26 17:36:00) [4]
ADO активно использует connection pooling и деактивацию объектов вместо их разрушения. То есть имеет смысл "отпускать" ADO соединение раз оно не нужно прямо сейчас. Повторная коннекция есть просто активация интерфейса и делается быстро и дешево.
Vlad (2003-11-26 17:05:00) [5]
> Johnmen © (26.11.03 16:56) [17]
Один из вариантов - создавать собственный коннект в потоке и пытаться открыть соединение. Но тут ты проверяешь на предмет того, есть ли связь с сервером вообще, т.е. не можешь увидеть что творится с основным коннектом.
Другой вариант - пытаться выполнить любые действия с БД через основной коннект, напр. запрос в try except, если сработал except, то попытка восстановить основной коннект.
На практике конечно я не проверял, но чесно говоря пока не вижу никаких препятствий.
Johnmen (2003-11-26 16:56:00) [6]
>Vlad © (26.11.03 16:47)
В том и проблема, как проверять ?
:)
Vlad (2003-11-26 16:47:00) [7]
> Johnmen © (26.11.03 16:35) [14]
Что мешает сделать поток, который будет проверять коннект раз в энное время ?
Calm (2003-11-26 16:37:00) [8]
> звонишь, а там тетка говорит
ну примерно так :))
Johnmen (2003-11-26 16:35:00) [9]
>Vlad © (26.11.03 16:17)
>...постоянно в программе отслеживать, не упал ли коннект
Меня интересуют (разумные) варианты решения этого.
Если не трудно, приведи их. :)
(MSSQL+ADO)
Vlad (2003-11-26 16:28:00) [10]
> LordOfSilence © (26.11.03 16:21) [12]
Это как у сотовых операторов, звонишь, а там тетка говорит, для получение такой-то инф-ции нажмите "1"... итд. В зависимости от нажатой кнопки прога разруливает звонки разным приложениям, к-рые рассчитывают напр. твой баланс на счете.
LordOfSilence (2003-11-26 16:21:00) [11]
А что такое "кол-центр", и что из себя представляют
"клиентские прилаги" в данном контексте?
Извини, не совсем понимаю эти термины.
Calm (2003-11-26 16:18:00) [12]
ok, БОЛЬШОЕ спасибо всем.
Vlad (2003-11-26 16:17:00) [13]
> Calm © (26.11.03 16:16) [8]
Никогда не слышал про такие ограничения.
Все что тебе надо, так это постоянно в программе отслеживать, не упал ли коннект, а если упал, то пытаться коннектиться заново.
LordOfSilence (2003-11-26 16:16:00) [14]
Я тоже советую держать коннект к базе постоянно под напряжением
Calm (2003-11-26 16:16:00) [15]
> Почему бы не держать постоянно открытое соединение ?
Да я собственно так и делаю.
Просто хотел уточнить, нет ли каких-либо ограничений на это дело.
Я использую ADOConnection.
Calm (2003-11-26 16:14:00) [16]
2 Nikolay M. © (26.11.03 16:11) [4]
Да все очень просто.
Девайс - внутренняя АТС. Клиенты - операторы кол-центра. Прога разруливает звонки на клиентские прилаги.
А если задержка более 2 секунд, то проще звонящего так спросить кто такой и чего надо.
Vlad (2003-11-26 16:14:00) [17]
> Calm © (26.11.03 16:12) [5]
Ну упавшую сетку ты программно никак не обойдешь :)
А вот траблы из-за медленного коннекта к базе когда нибудь обязательно всплывут. Так что держи лучше коннект открытым
Calm (2003-11-26 16:12:00) [18]
Специфика такова, что если сервак недоступен или сетка отвалилась, то прога уже ничем никому не поможет.
Данные актульны свего несколько секунд. А в БД пишутся для дальнейшего анализа. Если же данные не были получены клиентами, то и анализировать незачем.
Nikolay M. (2003-11-26 16:11:00) [19]
Не видел [1], когда писал [2].
Интересно, кому потребовалось обновлять данные с точностью до 2 секунд? Недавно один товарищ тут тоже dbgrid обновлял 10 раз в секунду...
Vlad (2003-11-26 16:11:00) [20]
Время коннекта к базе - штука непостоянная. Зависит от многих факторов. Может случиться так что тебе не хватит 2 секунды чтобы открыть соединение. Почему бы не держать постоянно открытое соединение ?
А если сетка падает и соединение обрывается, то временно пиши в кэш, напр. ClientDataSet