В косвенное продолжение темы коротких коннектов встал вопросик.

Есть толстый клиент, на старых добрых дельфях; можно его конечно пинать, рекомендовать жавы, вебы и прочую хрень, но пользователь категоричен - хочу толстую старушку, но через интернет. Может некрофилия, а может что-то в новом мире не так. Не суть вопроса.

А суть в чем.
Есть у клиента коннект и две транзакции. Одна читает - readonly и держится она постоянно, и есть пишущая - короткая, создается только для записи. Есть кучка сессионных переменных и временных таблиц (видимых в рамках сессии).
Рвется связь - кратковременно - меньше секунды - чаще всего из-за балансировки нагрузки на каком-то маршрутизаторе.
Клиент отваливается. На сервере остается висяк, который можно убить через mon$attachments, но сначала нужно угадать какой, и он (attacment) не знает что клиент помер...

Можно перепилить клиента чтобы он делал короткие коннекты на чтение, но тогда встает вопрос падения FB (о котором я писал раньше) и теряется прелесть временных таблиц.

Вопрос.
Существуют ли какие-то библиотеки/инструменты/решения чтобы повысить устойчивость соединения - не отрывать клиента при кратковременных сбоях сети.
Естественно не стоит вопрос вернутся в пишущую транзакцию - это не критично, можно сделать вторую попытку, но как сохранить соединение по чтению или воткнутся в старое, так чтобы сохранить сессионные настройки.
Ну или хотя бы не рвать связь при коротких обрывах (меньше пары секунд).
Да, и со стороны сервера - можно ли узнать что клиент отвалился?
в логе будет ошибка
INET/inet_error: send errno = 10054
но это не решает проблему...

Возможно вопрос глупый, а может уже есть какие-то библиотеки или идеи?
Самое забавное, что тонкого клиента под FB я не нашел.

Симонов Денисчто значит не нашёл тонкого клиента под ФБ? Тонкий клиент это архитектурное решение, а не какая-то готовая библиотека
да, я это понимаю.

Мимопроходящий01.02.2019 16:40, Игорь-PicoMed пишет:
> Клиент отваливается. На сервере остается висяк

http://www.ibase.ru/keepalive/


все это настроено, но проблему обрыва не решает

Всем спасибо за дельные советы.

Кратко подводя итоги.
1. По России шнур выдергивали и все работало, в Казахстане соединение падает постоянно, особенно когда сервер в Астане а подключение откуда-нибудь из Усть-Каменогорска. Причину так и не нашли. Есть мрачное предположение что с законом Яровой и в России начнется та же фигня.
2. Терминальное решение хорошо, но каналы нужны оооочень толстые
3. zebedee гоняли лет ...надцать назад. Думал что проект помер уже. Применяли для заказчиков-параноиков которые боялись перехвата по сети. Заметной устойчивости в стародавние времена он не добавлял.
4. тестили аппаратный VPN (не в РК) - действительно хорошо и стабильно, но дорого, за программные решения - спасибо - попробуем
5. за комментарии про трешку - тоже спасибо
6. много серверов и репликация, грустно как-то, особенно когда сервер на 2-3 клиента и серверов под сотню. Этот зоопарк потом замучишься обслуживать. Очень надеялся от этого уйти. Всем "облако" подавай... и центральные сервера, дабы на сисадминах экономить
7. кэширование "все и вся" в локальных таблицах - тоже странное решение (чем-то dbf-ами попахивает или BDE). Зачем тогда сервер? Зачем мощные инструменты базы, если все поисковые задачи будет выполнять клиент в локальных таблицах. Да и делать поиск по паре десятков тысяч строк на дерьмовеньком локальном компе [пример - поиск города в КЛАДР по контексту названия]- то еще удовольствие (и это не считая время на подгрузку кэша).
8. Трехзвенка c FireBird - идея давно в воздухе, но мне ничего приличного не попадалось, всё что крутится - вокруг MS SQL - может посоветуете что-то под FB?

MaratIskу тебя рудиментарные представления о трехзвенке :)
Все мы рано или поздно станем рудиментами )))

Поэтому и спрашиваю что и где можно почитать про современные решения.
Повторюсь - все что попадалось для тестов из трехзвенки давало кратные (в разы) провалы по быстродействию как по чтению так и по записи и лишало всей прелести возможностей FB сервера.

Можно спорить, где должна жить математика - в сервере базы или сервере приложений, но однозначно могу сказать, когда реакция системы на действие пользователя падает с 0,2 секунды до 2-3 секунд, то такой продукт улетит в помойку...
Современные интерфейсные технологии славятся своей "дружелюбностью" и "быстрым откликом" (как вы понимаете - это сарказм), но когда дело доходит до нормальных производственных задач, где гламур не важен, меня убедительно просят сохранить старый дельфийский софт, просто потому что интерфейс быстрее...
Вот и вопрос - что лучше - рудименты или ждать ответа глядя на красивое колесико...

[quot DmSer]Поэтому и спрашиваю что и где можно почитать про современные решения.

Очень много материала по современным решениям есть на habr.com . Причём "современные" не означаю "хорошие". Как правило это что-то лучшее из бесплатных технологий и это задаёт трэнд в программировании, адаптирует образовательный процесс в ВУЗах и позволяет работодателю без проблем находить новых специалистов. На сегодня тренд - это интерфейс пользователя на react-js и бэкенд на node-js / golang / php / aspnet core и т.п.
Разработка фронта на Sencha ExtJS и бэкенда на Delphi может даже будет более эффективна, но это совсем не тренд.

без обид, но "тренды" это жертва современного маркетинга.
"тренд" это то что сейчас ЛЕГКО продается, желательно без мозгов.
А задавали ли вы вопрос ЧТО продается?
Если взять меня - обожаю js (и 1С))) во всех ипостасях, когда нужно продать часы - быстро лепим дерьмо из готовых шаблонов, потом выкручиваем из заказчика много "часов" для приведения "этого" в рабочий вид, да еще убеждаем его, что ему нужно поменять весь парк железа, потому что новый фреймворк не поддерживается "современным" браузером.
Другой вариант - нужен "Продукт" для широкого круга заказчиков - нужна предсказуемость и стабильность. Нужно законченное решение, которое заказываться/покупается у разработчика. Заказчик не хочет платить за часы, ему нужно решение, которое будет работать на его паре тысяч компьютеров, часть из которых давно пора отправить в помойку.
Можно это слепить на js (для простых задач так и делаю, но приходится таскать с собой хромиум, чтобы хоть как-то обеспечить стабильность), но если задача сложная и еще ориентирована на пользователя с точки зрения ГУИ (в ...опу красоту - важна скорость, минимизация ошибок, целостность ввода информации) - вот тут, если сравнивать js и Delphi то скорость разработки (и цена) будет не в пользу js.
Увы, сегодняшний маркетинговый тренд - все в "облако", все на иглу "техподдержки", ширяйте мышкой до опупения, и пофигу, что очередь стоит. Меня как пользователя это бесит страшно, но это тренд.
Вопрос хорошо ли это?
Но это тема другой дискуссии.
Вопрос был о современных решениях в области трехзвенки под FB

kdvФэйтл Эра,

я бы сказал, "да и х с ним". Есть два типа коннектов, live и stateless. У Firebird/Interbase коннекты live. Это значит, что при обрыве коннекта контекст не сохраняется, надо делать переконнект и восстанавливать статус.
Stateless коннекты - это типа браузера по http, когда делаешь запрос, получаешь ответ, и дальше пофиг. Аналогично всякие модели briefcase, и прочее.
Автору топика надо stateless. Но это чревато, т.к. там всё по другому (в отличие от клиент-сервера) делается. Запросы надо целиком выфетчивать, показывать их по частям, и прочее.
В общем, автор топика опоздал лет на 20 с изучением трехзвенки.

Вы почти в точку попали.
Изучать трехзвенку начал лет двадцать назад, а с терминальными сессиями работал еще лет за десять до этого.
Правда никогда не считал терминальное подключение трехзвенкой. Да и тому, кто сможет поднять 200-300 терминальных ГУИ-сессий можно памятник поставить (из реальных подобных задач, только IKEA в голову приходит, да и то, кажется, они уже сдулись и на "толстого" клиента перешли)...

И насчет "живых" и "не живых" коннектов тоже - абсолютно в тему.
Естественно, понятны плюсы и минусы каждой из моделей.

Вопрос был в том, есть ли сейчас какие-то современные модели, которые позволяются обеспечить "условный live коннект" к ФБ при условии нестабильной связи.
Почему "условный" - потому что стабильность соединения хотелось бы контролировать на уровне клиента или сервера приложений - по принципу Stateless коннектов, но при этом не фетчить лишнего.

kdvДля Дельфи можно использовать и DataSnap. Но к нему претензии при большом количестве коннектов (клиентов, не к БД).
Можно использовать трехзвенку в виде веба - PHP и всякое. И т.д.

DataSnap - пробовали - к претензиям по стабильности на больших нагрузках полностью присоединяюсь
PHP - это тормоз, и рушит ФБ при большой нагрузке (гоняли на модели Classic 2.1-2.5)
и т.д. пока не пробовали, а хочется )))

Сисдба МастеркеевичИгорь-PicoMed PHP - это тормоз, и рушит ФБ при большой нагрузке (гоняли на модели Classic 2.1-2.5)Можно поподробнее ? Каким образом рушит ?
Пытаюсь добиться повторяемости ошибки. Как будет готов код и условия при которых падает база - напишу.
Хочу предварительно исключить косяки настроек операционки (в частности - на виртуально Window 2012 сервере ошибка проявляется в 15 раз чаще, чем на "железке") и иные, не зависящие от ФБ факторы

kdvИгорь-PicoMed которые позволяются обеспечить "условный live коннект" к ФБ
нет такого в принципе. Если такой коннект есть, то не к ФБ, а к серверу трехзвенки. Соответственно, к ФБ оно не имеет никакого отношения.

Очень жаль...
Хоть самому туннель писать.
Глупая идея - сервер (условно-трехзвенки или Proxi) держит пул коннектов/курсоров, а клиент подключается к нему по необходимости по принципу сессий. Обрыв связи не критичен - переподключение при сохранении сессии - всегда попадаем в нужное соединение/транзакцию.
Вроде и неживое и живое, одновременно...
Почему никто такого для ФБ не сделал? (для MS SQL о таких решениях слышал, но сам не копал, так как утверждалось, что заточено строго под мелкософт)