• Jboss и TomCat. Как это работает?

    iZENfire
    @iZENfire
    JBoss — это реализация спецификации JavaEE (контейнер для EAR- и WAR-приложений).
    Tomcat — это частичная реализация JavaEE в той её части, которая включает Web-приложения (контейнер для WAR).

    Один другого дополняет. Для работы всего этого нужен JavaSE JDK — Oracle JDK или OpenJDK6 или 7 — в зависимости от требований развёртывания.

    В WAR-приложениях сервлеты компилируются заранее Java-компилятором в байткод *.class-файлов и созданием архива с *.class-файлами и ресурсами (*.war). JSP-страницы из *.war компилируются «на лету» в сервлеты при первом запросе. Во время первого запроса со стороны пользователей контейнер сервлетов (Tomcat) преобразует JSP-страницы (если они присутствуют) в сервлеты, компилируя с помощью Java-компилятора из JDK в байткод. JVM контейнера осуществляет JIT-компиляцию байткода сервлетов в нативный код и кэширование нативного кода в оперативной памяти для обработки последующих запросов пользователей.

    В EAR-приложениях контейнер (JBoss) производит похожую работу совестно с JVM по JIT-компиляции бинов (файлы *.class в *.ear) и кэшировании нативного кода в оперативной памяти для последующего многократного выполнения.

    Метаинформация, записанная в файлах *.war и *.ear, нужна для правильного развёртывания, «параметризации» значений свойств сервлетов и бинов, частичным управлением жизненным циклом приложений.
    Ответ написан
    Комментировать
  • В чем принципиальное отличие unique (constraints) от unique index?

    alekciy
    @alekciy
    Вёбных дел мастер
    Разница в том, что ограничения (сonstraints) призваны обеспечивать целостность данных, а индексы (index) — скорость доступа к данным. Это две абсолютно не связанные сущности. Причем если первое — часть SQL стандарта, то второе нет (ибо ни как не связанно с функциональностью языка, введение индексов — вынужденная мера). Разработчик сам решает, в каких случая применить эти механизмы и использование одного вовсе не требует использование другого.

    Теперь касательно уникальности (unique). В данном случае при добавлении ограничения уникальности (unique constraint) Postgresql сам навешивает на указанное поле индекс. Это просто особенность реализации в данной СУБД. Разработчики решили, что вот так оно будет работать и все тут (причем небезосновательно). В другой же схожей ситуации они решили, что разработчик сам думает, нужно ли ему использовать этих два механизма вместе, или нет. Я говорю об ограничении целостности по внешнему ключу (foreign key). В Postgresql индексы по полям с данным видом ограничения не создаются (Индексы по внешним ключам в Postgresql). А, к примеру, в MySQL создаются. Это особенность реализации в MySQL.

    Поэтому важно просто понимать, что это не связанные вещи, просто в некоторых реализациях они «сцеплены» между собой и создание некоторых видов ограничений приводит к автоматическому созданию индекса.
    Ответ написан
    2 комментария