Технология распределения нагрузки между несколькими серверами сравнительно небольшой мощности является стандартной возможностью СУБД Caché уже достаточно давно. В её основе лежит протокол распределённого кэша ECP (Enterprise Cache Protocol); здесь имеется в виду именно «cache» («кэш»), а не «Caché» («кашЭ»). ECP открывает богатые возможности для горизонтального масштабирования прикладной системы, обеспечивая высокую производительность при не менее высокой устойчивости к отказам, оставляя при этом бюджет проекта в достаточно скромных рамках. К достоинствам сети ECP справедливо будет отнести и возможность сокрытия особенностей её архитектуры в недрах конфигурации СУБД, так что прикладные программы, изначально разработанные для традиционной (вертикальной) архитектуры, как правило, легко переносятся в горизонтальную ECP-среду. Эта лёгкость настолько завораживает, что хочется, чтобы так было всегда. Например, все привыкли к возможности управлять не только текущим, но и «чужими» процессами Caché: системная переменная $Job и связанные с ней функции и классы в умелых руках позволяют «творить чудеса». Стоп, но теперь процессы могут оказаться на разных серверах Caché… Ниже — о том, как удалось добиться почти такой же прозрачности в управлении процессами в среде ECP, как и без неё.

Несколько лет назад заказчик, крупный медицинский центр федерального значения, поручил нам разработать софт, обслуживающий информационные киоски. Внешне киоск напоминает платёжный терминал (только без купюроприёмника), его основная функция, как следует из названия, — предоставление пациентам различной информации, такой как расписание приёма врачей, услуги и их стоимость, и так далее.
По понятным причинам для киоска потребовалось разработать упрощённый интерфейс пользователя, который было решено реализовать как web-приложение. Имея в штате опытных web-программистов, уверенно владеющих php, решили (для скорости) поручить им его написание, организовав связь с базой данных нашей медицинской системы. Рассматривалось 3 варианта взаимодействия:

• ODBC
• JDBC
• web-сервисы.

Web-программисты предпочли ODBC как наиболее простой с их точки зрения вариант, и альфа-версия киоска довольно быстро увидела свет. Однако вскоре выяснилось (surprise!), что php-код должен работать не под Windows, как это было у разработчика, а под Linux, несмотря на то, что в те годы наша медицинская система эксплуатировалась заказчиком на платформе Windows 2008. Чтобы «подружить» всех членов триады (Linux – ODBC-драйвер Caché — php5) потребовались определённые усилия. Последовательность проделанных действий я зафиксировал в виде наброска к данной статье, которую и предлагаю вашему вниманию.

При работе с GUI и терминальными приложениями нередко случается, что пользователь, работая в режиме удаленного доступа (как правило, через Интернет), покинув компьютер минут на 15, по возвращении обнаруживает, что программа зависла. На любое действие она отвечает ошибкой, содержащей примерно такие фразы: «Потеряна связь с сервером», "[WINSOCK] virtual circuit reset by host" и т.п. Наблюдается такое и при выполнении «долгоиграющих» методов (запросов к серверу), в которых не предусмотрен вывод прогресс-бара или какая-либо интерактивность.

Данная проблема характерна не только для GUI и терминальных решений на базе СУБД Caché и Ensemble компании InterSystems, а вообще для любого клиент-серверного взаимодействия по протоколу TCP/IP. Обычно она решается на прикладном уровне путём периодического обмена пустыми сообщениями специального вида, предназначенными лишь для того, чтобы просигнализировать о том, что приложение «живо».

Ниже о том, как можно решать эту проблему без программирования.