Новая версия IBProvider v3.9 поставляется с гарантией(!) стабильной работы в составе круглосуточно функционирующих систем
Подумайте, доверяете ли вы своим компонентам доступа к Firebird и InterBase настолько, чтобы позволить им работать без присмотра в составе круглосуточно функционирующих программных комплексов?
Зрелость программного обеспечения определяется возможностью безотказной работы без оператора долгое время.
Можно закрывать глаза на тот факт, что:
- многие «программы» приходится перезапускать несколько раз в час из-за утечек памяти, зависаний, а так же неожиданных критических ошибок, которые закрывают приложение, к примеру, после десяти минут ввода несохраненного текста.
- при работе с большими объемами информации смотреть по нескольку часов на замершее окно приложения, в надежде, что этот отчет все же досчитается, и в итоге, придя утром на работу увидеть не готовую аналитику, а сообщение «Out of memory»
Гораздо хуже, если причина этих проблем не ошибка в вашем коде, а выбранные вами компоненты доступа к Firebird и InterBase.
Более 10 лет разработки компонент доступа и испытания их в составе круглосуточных систем для обработки огромных массивов информации, научили нас в компании IBProvider тому, что зрелые компоненты доступа должны использовать подход «максимальной терпимости к ошибкам клиента», вместо распространённого подхода «вы сами виноваты, думайте, что передаете серверу».
С одной стороны обычный драйвер может быть лишь прослойкой между сервером БД и клиентским приложением и без всякой обработки транслировать все, что передается от клиента на сервер. При таком подходе мы получаем именно те ситуации, о которых написано выше:
- зависания,
- ошибки переполнения памяти,
- критические ошибки, приводящие к потере всех несохраненных данных,
- плюс к этому еще и ошибки конвертации, а так же «магические» ошибки от самого сервера.
Подход максимальной терпимости к ошибкам подразумевает:
- Стратегию предотвращения проблем и перепаковку любых клиентских запросов в вид, дружелюбный для серверов InterBase и Firebird.
- Возможность обработки любых объемов информации любого типа (текст, видео, изображения, супермассивы и т.д).
- Автоматизацию
рутинных действий программиста, таких как:
- автоматическое определение описаний параметров команд.
- генерация команд update, delete, insert на основе команды select.
- возможность пакетного выполнения запросов к БД в одной команде (SQL-скрипты).
- контроль переполнения памяти и выгрузка объемных данных в собственный SWAP-файл на жестком диске.
- Реализацию
функций, которых нет в сервере, на уровне IBProvider. В том числе:
- вложенные транзакции
- типы данных Boolean, GUID даже для самых старых версий серверов
- Автоматическое
определение
типа сервера и настройка на работу с ним:
- определение списка ключевых слов, зарезервированных за RDBMS.
- настройка загрузчика метаданных.
- настройка парсера управляющих последовательностей (ODBC Escape Sequences).
- выбор алгоритма вложенных транзакций, а так же поддерживаемого диалекта.
- подключение алгоритмов, оптимизированных под конкретную версию сервера БД.
- и еще целый ряд индивидуальных настроек, о которых пользователи IBProvider даже не подозревают.
- Человеческое преобразование типов данных. В процессе тестирования IBProvider нам пришлось заменить много серверных алгоритмов своими, в том числе и конвертор типов.
Итак, в новой версии IBProvider v3.9 отказоустойчивость это:
- Новые отказоустойчивые алгоритмы при работе с большими массивами. Например — CHAR(30000) [-32000:32000,-32000:32000]. Оптимизированы операции чтения/записи массивов.
- Новые отказоустойчивые алгоритмы при работе с 4х-гигабайтными BLOB-полями в 32-битной Windows.
- Корректная поддержка 4х байтных символов UTF8 (обработка суррогатных символов, увеличенный размер WSTR-колонок).
- Улучшенная поддержка UNICODE_FSS. Реализованы принципиально новые алгоритмы преобразования в UCS2 и обратно.
- Устранена проблема с .Net Transaction Scope и «Unsupported Isolation Level». Теперь, в случае UNSPECIFIED (-1) уровня изоляции, провайдер использует уровень изоляции, определенный для всей распределенной транзакции. Обратите внимание, что по-умолчанию TransactionScope использует изоляции SERIALIZABLE. Другой уровень изоляции можно определить через TransactionOptions.
- Решена проблема работы с текстовыми массивами и кодовой страницей NONE.
- Сборка новой 64-битной версии IBProvider осуществляется на компиляторе VS. Net 2010, которая дает на выходе более производительный код меньшего размера. Еще один повод задуматься о плавном переходе на 64-битные приложения.
У нас нет времени на ручное тестирование всех вариантов работы IBProvider, поэтому мы проводим 1.44 миллиона тестов автоматически
Вероятно, вы заметили, что в IBProvider регулярно тестируются и устраняются критические ситуации, о которых программист не задумывается, пока это не случится: типы данных, кодировки, транзакции, большие объемы информации, многопоточность, крайние допустимые значения — все это подлежит автоматическому тестированию.
Согласитесь, что лучше предусмотреть максимум вариантов при тестировании компонент доступа, чем собирать свою коллекцию «чего нельзя делать» в процессе эксплуатации круглосуточной системы, когда она регулярно, по непонятным причинам, в ваше отсутствие будет завершать свою работу с критической ошибкой.
С 11 июня по 19 июля 2011 года мы провели интенсивное, многопоточное тестирование IBProvider и Firebird:
- System: Vista x64, Q6600, 8GB, RAID10 (4xWD RE3 1TB)
- IBProvider: x64, v3.8.2.12727, compiler: VS2010
- Firebird: x64, v2.5.1.26308, SuperClassic, compiler: VS2008
- Тесты: IBProvider Test System, 8 Threads.
И провайдер и сервер отработали 1.44 миллиона разнообразных тестов без каких-либо заметных проблем.
В завершении снова зададим вопрос, который поднимался в начале: