Месяц: Март 2014

  • Заметки по Derby DB

    Нельзя сказать, что к Derby DB у меня особо теплые отношения. Первое знакомство с ней произошло много лет назад, когда на работе возникла идея прикрутить Derby вместо полноценной базы данных, чтобы проще было готовить демку программы к выставке. Идея была в том, что если взять легковесную встраиваемую базу, то тогда развертывание демонстрационного дистрибутива сильно упростится — скопировал файлики и ничего настраивать не нужно (в отличие от Оракла). В случае если нам нужен всего-лишь выставочный демонстрационный образец ПО такое решение было вполне оправдано. Почему выбор пал в тот момент именно на дерби думаю сейчас мало уже кто вспомнит.
    В итоге конечно всё прикрутить получилось, но скорость работы базы на тот момент оставляла желать лучшего. Возможно где-то я был не прав (был молодым и неопытным), а возможно и сама база была “юной” и не достаточно расторопной. derby_db_logo

    С тех пор прошло много времени, Derby уже давно поставляется вместе с JDK под именем Java DB, поэтому думаю в жизни многих Java-программистов также возникали случаи совместной работы с этой удивительной базой данных. Собственно поэтому решил описать некоторые её капризы и особенности. Сразу хочу заметить, что эту БД использую в жизни не так часто и возможно именно поэтому ее поведение меня иногда удивляет.

    1.Кидается исключениями при отключении.

    Чтобы отключить БД в embedded режиме, нужно в JDBC-URL прописать “jdbc:derby:;shutdown=true”. Если всё нормально, в вас обязательно при отключении кинут исключением SQLException с кодом XJ015. К этому нужно привыкнуть и не пугаться.

    2.Режим использования RAM (In-memory).

    У Derby есть не плохой экспериментальный режим, когда она работает в памяти.
    Удобно использовать для создания временного окружения (чтобы не удалять созданные файлы и директории) или в различных jUnit-тестах.
    Опять таки все делается через URL, например для создания пишем: “jdbc:derby:memory:myDB;create=true”.

    При этом если вы сделаете shutdown, но не потушите JVM, то ваша БД не почистится. Чтобы удалить данные из памяти нужно сделать сделать drop (jdbc:derby:memory:myDB;drop=true), который сам сделает shutdown:
    You can shut down an in-memory database using the shutdown=true attribute before you drop the database, but this is optional. Dropping the database also performs the shutdown.

    3.JRE7u51

    В JRE7u51 поменялись ограничение в настройках безопасности. Поэтому при запуске дерби в сетевом режиме могут валиться исключения AccessControlException.
    На официальной странице oracle предлагается решение, в котором необходимо настроить собственный security.policy файл, чтобы в нем был доступ к порту (по-умолчанию 1527). Например так:

    grant {
        permission java.net.SocketPermission "localhost:1527", "listen";
    };
    

    Хорошая пошаговая инструкция на странице администрирования.

  • Распараллеливание задач в Java через InvokeAll

    Одно время у меня были некоторые сомнения имеет ли смысл публиковать эту статью, т.к. в целом мне нечего сказать такого, что нельзя было найти в официальной документации об invokeAll. Затем, при общении с другими программистами, стал время от времени замечать не совсем правильное (на мой взгляд) понимание его работы. Поэтому пока есть свободное время решил все-таки закончить эту заметку.

    Сразу хочу заметить, что мне не очень хочется углубляться в описание всей мощи java concurrent API, а просто расставить некоторые акценты при работе над небольшой простой задачей. Она может возникнуть в жизни каждого программиста, он замечает некоторые независимые операции и у него появляется нестерпимое желание их распределить по нескольким потокам. Грубо говоря, у вас есть какой-то метод, который можно было бы безболезненно запихнуть в Runnable-ы, стартануть и подождать когда все закончат свою работу.

    Понятно, что для этого может подойти invokeAll т.к. в описании про него явно сказано: “Executes the given tasks, returning a list of Futures holding their status and results when all complete.”

    Так вот, некоторые программисты не дочитывают последние слова и думают, что нужно самому контролировать процесс, ждать и “жать на тормоз”, проверять все ли потоки завершились, периодически дергать в цикле future.get(), join-ить или делать другие различные телодвижения. Конечно так поступают не все, но тем не менее такое бывает. Для того, чтобы разобраться в том, что происходит на самом деле, достаточно взглянуть в базовую реализацию этого метода (AbstractExecutorService.java). Надо же пользоваться тем, что src.zip в JDK все еще продолжают подкладывать: (далее…)

  • DCE VM + HotSwap

    Горячая замена.

    Исходной предпосылкой было как-то упростить процесс разработки/отладки. В некоторых ситуациях, например когда запуск-перезапуск приложения или теста занимает продолжительное время, очень удобно пользоваться возможностью подправить логику работы уже запущенной программы.
    В поисках решения наткнулся на довольно занятное решение – Dynamic Code Evolution VM. Данная виртуальная машина является результатом работ проведенных в рамках исследовательского проекта Институтом системного программного обеспечения им. Иоганна Кеплера в г. Линце (Австрия).

    Если грубо описать полученный результат – это специальная “пропатченная” Java VM, которая позволяет на лету править классы в работающей машине. Главная плюшка – если обычно при дебаге вы можете “на горячую” менять содержимое метода, то в DCE VM можно еще и добавлять/удалять методы и поля в классе.

    К сожалению с установкой DCE VM у меня не заладилось с самого начала. Инсталлятор не сработал, в итоге пришлось просидеть полночи в попытках заполучить эту чудную VM. К решению этой задачи пробовал подступиться с разных сторон. Пытался собрать исходники. Собирать пришлось из под cygwin-а (в очередной раз пожалел, что сейчас у меня рабочая операционка не Linux). Потом возникли сложности с установкой “Microsoft SDKs Windows v7.1”, который почему-то не хотел устанавливаться. В итоге, правдам и неправдами, перед самым рассветом, перерыв кучу ссылок в интернете различными кривыми путями мне удалось стать счастливым обладателям этой машинки. Конечно сейчас, оглядываясь назад, у меня создается впечатление, что на самом деле я сделал кучу лишних шагов и про установку DCE VM информации более чем достаточно, главное внимательно читать инструкцию.

    Мои эксперименты.

    После того как всё настроил Hot Swap заработал сразу на:

    • Простых Java SE проектах.
    • Java Web проектах под Apache Tomcat.

    Схема работы простая. Запускаем под дебагом → Делаем изменения → Жмем Apply Changes.

    apply_code_changes

    Если речь идёт о более экзотических случаях, например разработка Rich приложений на Netbeans Platform – то горячая замена у меня не заработала. Чуть позже у меня появилась гипотеза, что возможно это связано с тем, что у Netbeans Platform свой ClassLoader. Возможно гипотеза неверна и дело в настройках, думаю в свободное время посмотреть более внимательно исходники проекта и утилит, которые идут вместе с ним. (далее…)