Правильно ли круглосточно поддерживать соединение к БД?

← →
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]

> звонишь, а там тетка говорит

ну примерно так :))

> Johnmen © (26.11.03 16:56) [17]

Один из вариантов - создавать собственный коннект в потоке и пытаться открыть соединение. Но тут ты проверяешь на предмет того, есть ли связь с сервером вообще, т.е. не можешь увидеть что творится с основным коннектом.
Другой вариант - пытаться выполнить любые действия с БД через основной коннект, напр. запрос в try except, если сработал except, то попытка восстановить основной коннект.
На практике конечно я не проверял, но чесно говоря пока не вижу никаких препятствий.

← →
me (2003-11-26 17:36) [19]

ADO активно использует connection pooling и деактивацию объектов вместо их разрушения. То есть имеет смысл "отпускать" ADO соединение раз оно не нужно прямо сейчас. Повторная коннекция есть просто активация интерфейса и делается быстро и дешево.

> me (26.11.03 17:36) [19]

Сдается мне ты что-то с трехзвенкой путаешь.
Пул коннектов создает COM+ приложение и действительно не закрывает сессию как таковую. А сервер БД тут причем ?

>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]

Правильно ли круглосточно поддерживать соединение к БД? Найти похожие ветки