Статьи по меткам ‘oracle’

Почему я не люблю фреймворки

Март 20th, 2012

Вернее, так. Есть фреймворки плохие, а есть фреймворки относительно хорошие. Хороших фреймворков я пока встречал мало.
В моём понятии хороший фреймворк — это библиотека/система, готовая работать 24/7 в течение нескольких лет без серьёзного сбоя.
Под серьёзным сбоем понимается сбой в работе приложения, после которого невозможно восстановить изначальный цикл его функционирования без перезапуска, а также утечка памяти.
Под нормальными сбоями я понимаю такие ситуации, как обрыв сетевого соединения, временная нехватка места на файловой системе, некорректный формат подаваемых на вход данных или иная временная занятость некоторого ресурса.

Теперь более подробно рассмотрим вопрос применительно к тем Java-фреймворкам, которые приходится часто юзать.

К относительно хорошим фреймворкам относятся java-библиотеки производства Apache. Код в них вылизан достаточно качественно, можно ловить все нештатные ситуации.

К совершенно плохим фреймворкам относится Hibernate. Эта сука готова жрать память до посинения, а также время на выполнение кучи однострочных SELECT’ов для выдёргивания массивов объектов из БД.

Также к хреновым фреймворкам относятся JDBC-драйверы Oracle. Есть у них такое поганое свойство, как мёртвое зависание на socketRead0, например, и баги с байндингами. Это, конечно, решается, но только плясками с бубном.

Относительно хороший фреймворк — это Ganymed SSH. Если бы не некоторые косяки опять же с тем же socketRead0, зависание на котором ну никак не отловишь без бубна, было бы вообще зашибись.

А вот ещё один хреновый фреймворк, к сожалению, — это Hyper SQL Database. Очень много багов, когда возникает необходимость держать эту базу 24/7. Подтверждение тому — ряд багов, созданных мной в рамках разработки одного-единственного проекта:
OutOfMemory error
Integrity constraint violation
SQLException with NullPointerException in cause
Invalid sequence number generation on UPDATE in MERGE stmt
Perfectly invalid date/time truncation in TRUNC() function
PSM (PL/SQL) routines do not see variables in MERGE statement

При этом задача примитивнейшая: по входным данным посчитать в БД статистику (через несколько инструкций MERGE) и сохранить в таблице, а потом её же выгрузить SELECT’ом в файл.

Sequoia — вообще непонятно зачем создан и для кого. Ужасный фреймворк, о нём я писал раньше: 1, 2, 3, 4.

Ну, и сама Java Virtual Machine — относительно хороший фреймворк. Сбоит хоть метко, но редко, и то ненамеренно положить удавалось только отдельные версии jdk.

Sequoia изнутри: заключение

Август 28th, 2009

Разбор полётов

В общем, сегодня решил, что ну её нафиг, эту Sequoia. Ибо я так и не нашёл в сети реализации класса, выполняющего бэкап данных СУБД ORACLE для Sequoia.
Разработчики много чего обещают, пророчат чуть ли не светлое будущее, а на самом деле ничего сверхнового и революционного в ней нет.
Изначально я думал, что разработчики написали свой парсер SQL-выражений под каждый движок, на деле же всё оказалось проще и прозаичнее: SQL-запросы тупо транслировались в базы.
Про атомарность транзакций я вообще молчу: в подобной архитектуре она в принципе не может быть реализована.
» Читать дальше: Sequoia изнутри: заключение

Sequoia изнутри #3

Август 27th, 2009

Пролог

В предыдущем посте я описал, на какие грабли пришлось наступить, чтобы заставить Sequoia создавать таблицы в RecoveryLog и запускать backends. Тем не менее, сама работа контроллера по-прежнему оставалась некорректной, и, как выяснилось, без правки исходников решить проблему никак не получалось.
» Читать дальше: Sequoia изнутри #3

Sequoia изнутри #2

Август 27th, 2009

Введение

Собственно, после первой неудачи с RAIDb1, изложенной в этом посте, я решил воспользоваться такой фичей, как RecoveryLog. Для этого ещё раз перечитывал туториал по созданию виртуальной БД.
» Читать дальше: Sequoia изнутри #2

Sequoia изнутри #1

Август 27th, 2009

Как бэ вступление

По работе возникла необходимость синхронной рабты с кластером БД (4 базы, в которых должны храниться одни и те же данные). Для этого я несколько месяцев подряд писать тулзу data_proc (коммерческая разработка), которая обрабатывает данные в поточном режиме и устойчива к connection-loss/database-failure ошибкам. Единственный недостаток — это хранение данных на локальном диске в виде журналов, объём которых достаточно велик, если база несколько часов находится offline.
Помимо data_proc у нас есть ещё куча других приложений, для которых пришлось писать балансировщик нагрузки для SELECT-запросов, с чем мы успешно справились. Тем не менее, вопрос балансировки нагрузки и кластеризации (с целью упрощения data_proc) остался, и мне предложили разобраться с C-JDBC, о чём я и буду сейчас писать.
» Читать дальше: Sequoia изнутри #1