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