Всем привет!

Знаю немного Spring и Hibernate.
Но еще хуже знаю EJB.
Но есть желание улучшить свои знания.

Попала в руки книжка Mastering Enterprise JavaBeans™ 3.0

Подскажите есть ли смысл глубоко изучить EJB? Или лучше углубить знания Spring и Hibernate? И действительно ли существует тенденция перехода в сторону легковесных решений? (коим является Spring)

Заранее Спасибо Всем.

Regards,
Alexander.

Здравствуйте, alex47, Вы писали:

A>Подскажите есть ли смысл глубоко изучить EJB? Или лучше углубить знания Spring и Hibernate?

Имхо, распыляться не стоит. Но вообще вопросы спорный. Сами решайте.

A>И действительно ли существует тенденция перехода в сторону легковесных решений? (коим является Spring)

Если судить по этой конференции, то да. Сейчас Spring пихают даже туда, где он не особо-то и нужен.

Здравствуйте, slskor, Вы писали:

S>Сейчас Spring пихают даже туда, где он не особо-то и нужен.

Например?

Здравствуйте, alex47, Вы писали:

A>Подскажите есть ли смысл глубоко изучить EJB? Или лучше углубить знания Spring и Hibernate? И действительно ли существует тенденция перехода в сторону легковесных решений? (коим является Spring)

Что касается Hibernate то скорее всего разницы скоро не будет, так как товарищи из JBOSS позиционируют его сейчас как реализацию persistance EJB 3.0.
Вообще щас весь JBOSS над этим бъется.
Что касается EJB 3.0 вообще то конечно она лучше чем 2.1. Но там нет многого что есть в Spring. Но не надо забывать что EJB это все таки производственный стандарт, а Spring — нет. К тому же комерческие реализации EJB часто предлагают всякие вкусные вещи типа распределенных транзакций, Spring же, на сколько я знаю, транзакции работают только на уровне базы данных, что не всегда удовлетворительно.

Хотя сам я использую Spring и всем советую, но и очень крупных проэктов с ее участием я не писал.
К тому же на базе Spring есть еще ну очень пролезные подпроэкты типа Webflow и Acegi.

N>...
N>К тому же комерческие реализации EJB часто предлагают всякие вкусные вещи типа распределенных транзакций, Spring же, на сколько я знаю, транзакции работают только на уровне базы данных, что не всегда удовлетворительно.

JOTM Transactions In Spring And Hibernate
Jencks — Lightweight JCA container which is easy to deploy inside Spring

Здравствуйте, ENP, Вы писали:

N>>К тому же комерческие реализации EJB часто предлагают всякие вкусные вещи типа распределенных транзакций, Spring же, на сколько я знаю, транзакции работают только на уровне базы данных, что не всегда удовлетворительно.

ENP>JOTM Transactions In Spring And Hibernate

имхо, качество JOTM не выдерживает никакой критики... "с виду ласточка, но с боку..."

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, ENP, Вы писали:

N>>>К тому же комерческие реализации EJB часто предлагают всякие вкусные вещи типа распределенных транзакций, Spring же, на сколько я знаю, транзакции работают только на уровне базы данных, что не всегда удовлетворительно.

ENP>>JOTM Transactions In Spring And Hibernate

C0s>имхо, качество JOTM не выдерживает никакой критики... "с виду ласточка, но с боку..."

А можно конкретные претензии?

В простом сценарии (либо закоммитить JMS и Hibernate операции, либо откатить обе) все работало.

И к слову: есть еще Geronimo Transaction Manager, который также можно использовать автономно.

Здравствуйте, ENP, Вы писали:

C0s>>имхо, качество JOTM не выдерживает никакой критики... "с виду ласточка, но с боку..."

ENP>А можно конкретные претензии?

по коду уже не смогу — я его всерьез рассматривал полгода назад для применения в проекте
что делал: скачивал код, смотрел на баглист, прикручивал к томкату и думал

собственно, основное сомнение закралось в процессе анализа HOWL — другой их разработки, которую они используют в качестве реализации для рековери-лога координатора
мне показалось, что допускается ситуация, когда данные лога не попадут на диск. там достаточно запутанный код, в котором flush-ем заправляет отдельный деймон-тред. лично мне все это кажется более, чем подозрительным, ибо по моим представлениям для полной гарантии выталкивания данных на жесткий диск нужно не java писать, а на чем-то более близком к платформе, чтобы пользоваться напрямую API этой платформы, которое бы давало гарантии флаша данных на диск.

возможно я излишне мннителен, но если учеть, что по внешним признакам выглядит, что objectweb как-то уже болт положил на jotm (релиз более, чем годичной давности, не исправляются зависшие баги, версия, включенная в jonas вроде более поздняя, но не понятно что мешает сделать отдельный релиз и т.д. и т.п.), как-то не хочется брать продукт, насчет которого есть сомнения в сбоеустойчивости и не видно, чтобы люди его продолжали поддерживать и развивать (хз, может изначальных авторов там уже и нет?)

ENP>В простом сценарии (либо закоммитить JMS и Hibernate операции, либо откатить обе) все работало.

простые сценарии работают. а сложные — с рековери вам доводилось испытать?

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, ENP, Вы писали:

C0s>>>имхо, качество JOTM не выдерживает никакой критики... "с виду ласточка, но с боку..."

ENP>>А можно конкретные претензии?

C0s>по коду уже не смогу — я его всерьез рассматривал полгода назад для применения в проекте
C0s>что делал: скачивал код, смотрел на баглист, прикручивал к томкату и думал

C0s>собственно, основное сомнение закралось в процессе анализа HOWL — другой их разработки, которую они используют в качестве реализации для рековери-лога координатора
C0s>мне показалось, что допускается ситуация, когда данные лога не попадут на диск. там достаточно запутанный код, в котором flush-ем заправляет отдельный деймон-тред. лично мне все это кажется более, чем подозрительным, ибо по моим представлениям для полной гарантии выталкивания данных на жесткий диск нужно не java писать, а на чем-то более близком к платформе, чтобы пользоваться напрямую API этой платформы, которое бы давало гарантии флаша данных на диск.

А что, есть в природе реализации, использующие API платформы?

C0s>возможно я излишне мннителен, но если учеть, что по внешним признакам выглядит, что objectweb как-то уже болт положил на jotm (релиз более, чем годичной давности, не исправляются зависшие баги, версия, включенная в jonas вроде более поздняя, но не понятно что мешает сделать отдельный релиз и т.д. и т.п.), как-то не хочется брать продукт, насчет которого есть сомнения в сбоеустойчивости и не видно, чтобы люди его продолжали поддерживать и развивать (хз, может изначальных авторов там уже и нет?)

А какие есть альтернативы?

ENP>>В простом сценарии (либо закоммитить JMS и Hibernate операции, либо откатить обе) все работало.

C0s>простые сценарии работают. а сложные — с рековери вам доводилось испытать?

Нет. Во-первых, в простом сценарии у меня вполне работает такая конфигурация:

    <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="driverClassName" value="org.postgresql.Driver"/>
        <property name="url" value="jdbc:postgresql://localhost/activemq"/>
        <property name="username" value="activemq"/>
    </bean>
    <bean id="hibernateSessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
        <property name="dataSource" ref="dataSource"/>
        <property name="mappingResources">
            <list>
                <value>messages/model/model.hbm.xml</value>
            </list>
        </property>
        <property name="hibernateProperties">
            <props>
                <prop key="hibernate.dialect">org.hibernate.dialect.PostgreSQLDialect</prop>
                <prop key="hibernate.cache.provider_class">org.hibernate.cache.NoCacheProvider</prop>
                <prop key="hibernate.cache.use_second_level_cache">false</prop>
                <prop key="hibernate.generate_statistics">true</prop>
                <prop key="hibernate.use_sql_comments">true</prop>
                <prop key="hibernate.show_sql">true</prop>
        <prop key="hibernate.hbm2ddl.auto">update</prop>
        </props>
        </property>
    </bean>

Менеджер транзакций прикрепляется только к JMS и к Message-Driven POJO:

    <bean id="jotm" class="org.springframework.transaction.jta.JotmFactoryBean"/>
    <bean id="jotmTransactionManager" class="org.springframework.transaction.jta.JtaTransactionManager">
        <property name="userTransaction" ref="jotm"/>
    </bean>
    <bean id="jmsConnectionFactory" class="org.jencks.pool.PooledSpringXAConnectionFactory">
        <property name="connectionFactory">
            <bean class="org.apache.activemq.ActiveMQXAConnectionFactory">
                <property name="brokerURL" value="tcp://localhost:5000" />
            </bean>
        </property>
        <property name="transactionManager" ref="jotm"/>
    </bean>        
        <bean id="listenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
        <property name="connectionFactory" ref="jmsConnectionFactory"/>
        <property name="destinationName" value="messages.input"/>
        <property name="messageListener" ref="messageListener"/>
        <property name="transactionManager" ref="jotmTransactionManager"/>
    </bean>
    <bean id="messageListener" class="jta.spring.MessageListener">
        <property name="hibernateSessionFactory" ref="hibernateSessionFactory"/>
    </bean>

И commit/rollback работает.

Я помню, что вы как-то говорили о том, что "надо еще, чтобы правильно были настроено такое свойстве hibernate, как hibernate.transaction.factory_class (его значением, например, может быть org.hibernate.transaction.JTATransaction)" Если я пытаюсь в качестве DataSource использовать org.postgresql.xa.PGXADataSource, я получаю: "Failed to convert property value of type [org.postgresql.xa.PGXADataSource] to required type [javax.sql.DataSource] for property 'dataSource'; nested exception is java.lang.IllegalArgumentException: No matching editors or conversion strategy found". Установка hibernate.transaction.factory_class сама по себе тоже приводит к "Failed to instantiate TransactionFactory". Т.е. неправильный способ работает, а правильный — нет. Если у вас есть соображения, отчего это происходит, и как в окружении Spring заставить работать правильный способ (а также, нужно ли это делать) — поделитесь ...

И еще: как в этой конфигурации (получаем сообщение и сохраняем его в БД) проверить рековери?

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, slskor, Вы писали:

S>>Сейчас Spring пихают даже туда, где он не особо-то и нужен.

B>Например?

едиственное место которое я знаю — так это J2ME, и то спорно!

Здравствуйте, ENP, Вы писали:

ENP>А что, есть в природе реализации, использующие API платформы?

на 100% не поручусь, ибо исходников не видел, но в Borland AppServer координатор — нативный процесс, запускающийся вообще без java. соответственно, бинарники под разные ОС — разные

ENP>А какие есть альтернативы?

основная альтернатива — использовать аппсервер, в котором по определению присутствует поддержка. собственно, это один из ключевых моментов всего обсуждения — если spring, то для ряда "требовательных" приложений нам нужно искать серьезные тулы, а если ejb — то тулы обязан предоставить аппсервер

C0s>>простые сценарии работают. а сложные — с рековери вам доводилось испытать?

я говорил про конфигурацию координатора (jotm.properties с jotm.recovery.Enabled=true и каким-то подбором значений для свойств howl.log.*)
естественно, координатор запускается отдельным процессом

ENP>И еще: как в этой конфигурации (получаем сообщение и сохраняем его в БД) проверить рековери?

ну, видимо, выдергиванием шнура питания у компьютера во время коммита транзакции, на котором координатор работает (предварительно следует расставить delays в коде jotm аккурат после завершения шага prepare).при перезагрузке этого компьютера надо наблюдать, как оживает координатор, что делать начинает, как другие процессы себя ведут — так, собственно, протестируешь устойчивость координатора и способность его соблюдать консистентность транзакционного лога

ENP>Если у вас есть соображения, отчего это происходит, и как в окружении Spring заставить работать правильный способ (а также, нужно ли это делать) — поделитесь ...

да я вроде не замечен в списках энтузиастов спринга

Здравствуйте, Blazkowicz, Вы писали:

S>>Сейчас Spring пихают даже туда, где он не особо-то и нужен.

B>Например?

Это мое лично мнение =)

Я сторонник простых архитектур. Простые архитектурные решения быстрее реализуются, потенциально меньше глючат. Для реализации простых решений не требуется слишком высокий уровень навыков и знаний у разработчиков. У меня в жизни МНОГОКРАТНО случались ситуации, когда неоправданное применение сложных решений не приносило ничего, кроме лишних проблем.

К примеру, разрабатывается несложный web-сайт. Что может дать Spring? Извините, но IOC сам по себе не так уж и ценен. Без него прекрасно можно прожить. Автоматическое управление транзакциями? Да, это хорошо. Но, скажем, применяя iBatis, я получу то же самое. Возможности Spring как клея между разнородными технологиями тоже окажутся мало востребованными, если я использую всего пару библиотек (для построения UI и доступа к БД).

Ну и есть еще один мелкий, но очень веский для меня довод. Недавно имел возможность сравнить связки Wicket+iBatis и Wicket+Spring+Hibernate. Допустим, я делаю некоторые изменения в коде. Resin/Tomcat автоматически перезагружает приложение. Первая связка перезагрузится на порядок быстрее, я быстрее увижу результаты внесенных изменений, то есть смогу работать более производительно. Суммарная экономия времени очень большая получается. Для кого-то этто мелочь, для меня — нет.

С другой стороны, я участвовал в разработке сервера приложений с модульной архитектурой. Доступ к бизнес-логике приложения должен был происходить несколькими способами: через web, через Hessian, через самодельные протоколы. Для таких задач Spring подошёл превосходно и если потребуется написать что-то аналогичное — возьму Spring без колебаний.

Здравствуйте, slskor, Вы писали:

S>Я сторонник простых архитектур. Простые архитектурные решения быстрее реализуются, потенциально меньше глючат. Для реализации простых решений не требуется слишком высокий уровень навыков и знаний у разработчиков. У меня в жизни МНОГОКРАТНО случались ситуации, когда неоправданное применение сложных решений не приносило ничего, кроме лишних проблем.

Не путай. Сложное решение это EJB а не Spring. Последние несколько проектов были именно небольшие веб приложения — десяток страниц, 3-4 формы. Ниразу не пожалел что использовали Spring. А без IoC можно и в 3х классах запутаться с инициализацией. Как сейчас помню, сидишь как дурак изобретаешь что когда должно инитится и где надо синглтоны прикручивать для этого.

Здравствуйте, slskor, Вы писали:
S> Автоматическое управление транзакциями? Да, это хорошо. Но, скажем, применяя iBatis, я получу то же самое.

Можно про это чуть подробнее? ...

Здравствуйте, Alex EXO, Вы писали:

AE>Здравствуйте, slskor, Вы писали:
S>> Автоматическое управление транзакциями? Да, это хорошо. Но, скажем, применяя iBatis, я получу то же самое.

AE>Можно про это чуть подробнее? ...

Вас интересует автоматическое управление транзакциями в iBatis? Все очень просто. Надо пользовать не только iBatis SqlMap, но и iBatis DAO (см. jpetstore для примера). Вот классический подход к управлению транзакциями:

ProductDao productDao = (ProductDao) daoManager.getDao (ProductDao.class);
try {
  daoManager.startTransaction();
  Product product = productDao.getProduct (5);
  product.setDescription (“New description.”);
  productDao.updateProduct(product);
  daoManager.commitTransaction();
} finally {
  daoManager.endTransaction();
}

Однако, в iBatis Developer Guide сказано:

In addition to programmatically demarcating transactions, you can allow the DaoManager to automatically
start and end a transaction for you... You don’t need to do anything special to use the autocommit behavior, just don’t call startTransaction(). Here’s an example:

Product product = productDao.getProduct (5); // Transaction 1
product.setDescription (“New description.”);
productDao.updateProduct(product); // Transaction 2
product = productDao.getProduct (5); // Transaction 3

If the updateProduct() method contained more than a single update, those updates within the method
definition itself would both be part of Transaction 2, so this type of “autocommit-like” semantic is much
more powerful and simpler too! Notice that in the above example there is no exception handling. It is all
taken care of internally to ensure that, in the event of an exception, transactions are rolled back (if
necessary) and resources are released.

Итак, если не стартовать транзакции явно, и разрабатывать методы ProductDao из того расчета, что они должны отрабатывать в контексте одной транзакции, то мы и получаем автоматическое управление транзакциями.

В Spring для тех же целей можно использовать TransactionProxyFactoryBean. Принцип примерно такой же: есть метод интерфейса, есть его реализация. Метод либо выполняется целиком в контексте транзакции, либо откатывается целиком в случае возникновения исключительной ситуации. Можно еще указывать, какие конкретно методы будут транзакционными при помощи аннотаций. Для этого надо использовать AnnotationTransactionAttributeSource. Безусловно, такой подход навороченнее и гибче, но в большинстве случаев хватает и того, что умеет iBatis.

Кстати iBatis DAO можно использовать для управления транзакциями в связке с Hibernate.

Здравствуйте, slskor, Вы писали:

S>Здравствуйте, Alex EXO, Вы писали:

AE>>Здравствуйте, slskor, Вы писали:
S>>> Автоматическое управление транзакциями? Да, это хорошо. Но, скажем, применяя iBatis, я получу то же самое.

AE>>Можно про это чуть подробнее? ...

S>Вас интересует автоматическое управление транзакциями в iBatis? Все очень просто. Надо пользовать не только iBatis SqlMap, но и iBatis DAO (см. jpetstore для примера). Вот классический подход к управлению транзакциями:

Ага спасибо.

Я тут решил таки прояснить себе ситуацияю с производительностью...
Сделал пример на hibernate и ibatis.
При этом заточил запросы в ibatis так, чтобы они совпадали с тем, что генерирует hibernate. И работали над теми же таблицами.
(Разумеется ручками их можно было сделать попроще, но пусть это будет некая фора хибернату...)
Управляющий тестом алгоритм взял один и тот же. То есть различались только собственно классы операций с объектами.
(Кстати, их объем оказался одинаковым в строках, не смотря на то что ibatis вроде бы уровнем пониже.)

Резултат
Если у ibatis и hibernate настроить кеш так, чтобы совпал объем занимаемой памяти, то hibernate пригрывает в 3-4 раза.
Если дать hibernate кешь такой, что в него влазит вся тестовая база, то разрыв сокращается до 2 раз (но это в практике малореальный случай).

При этом hibernate ел 98% процессорного ресурса, а у ibatis загрузка не поднималась выше 16% (остальное время видимо ждал ответ от sql).

В общем получается, что расходы на дополнительный абстрактный слой весьма немаленькие... не ожидал я такого.

Здравствуйте, Alex EXO, Вы писали:

AE>Я тут решил таки прояснить себе ситуацияю с производительностью...
AE>Сделал пример на hibernate и ibatis.

Слова-слова. Код в студию!

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Alex EXO, Вы писали:

AE>>Я тут решил таки прояснить себе ситуацияю с производительностью...
AE>>Сделал пример на hibernate и ibatis.

B>Слова-слова. Код в студию!

Весь проект запаковать мого всякой фигни получится, так что ставлю только код:

Общая часть:

Объектик...

public class TestModel {
    private int id;
    private String value;
    private int is_archive;

    public int getId() {
        return id;
    }
    public void setId(int id) {
        this.id = id;
    }
    public String getValue() {
        return value;
    }
    public void setValue(String value) {
        this.value = value;
    }
    public int getIs_archive() {
        return is_archive;
    }
    public void setIs_archive(int is_archive) {
        this.is_archive = is_archive;
    }
}

Набор операций

public interface ITest {
    public Integer addElem(String value) throws Exception;
    public TestModel getElem(Integer id) throws Exception;
    public List<TestModel> getList() throws Exception;
    public void setElem(TestModel model)  throws Exception;
    public void deleteElem(Integer id) throws Exception;
}

Тестовая функциешка

    private void test_model(ITest test) throws Exception {
        for(int i=0; i<100; i++)
            test.addElem(new Integer(i).toString());
        List<TestModel> list = test.getList();
        for(TestModel model : list)
        {
            TestModel model_i = test.getElem(model.getId());
            model_i.setValue(model.getValue()+"**");
            test.setElem(model_i);
            test.deleteElem(model_i.getId());
        }
    }

и ее вызов

        Calendar start=Calendar.getInstance();
        for(int i=0; i<100; i++)
            test_model(testObject);
        Calendar end=Calendar.getInstance();
        Long d = end.getTime().getTime() - start.getTime().getTime();

---------------------------------
Специфичное для hibernate

<hibernate-configuration>

    <session-factory>

        <property name="hibernate.connection.driver_class">org.postgresql.Driver</property>
        <property name="hibernate.connection.url">******</property>
        <property name="hibernate.connection.username">****</property>
        <property name="hibernate.connection.password">****</property>
        <property name="hibernate.dialect">org.hibernate.dialect.PostgreSQLDialect</property>

        <property name="hibernate.connection.autoReconnect">true</property>
        <property name="hibernate.connection.pool_size">10</property>
        <property name="hibernate.connection.useUnicode">true</property>
    <property name="hibernate.connection.characterEncoding">UTF-8</property>
    <property name="hibernate.transaction.auto_close_session">true</property>
    <property name="hibernate.connection.autocommit">true</property>
        <property name="hibernate.show_sql">true</property>
        <property name="hibernate.show_sql">false</property>
        <property name="hibernate.jdbc.batch_size">50</property>
    <property name="hibernate.cache.provider_class">org.hibernate.cache.OSCacheProvider</property>

        <property name="hibernate.hbm2ddl.auto">create-drop</property>
        <mapping resource="TestModel.hbm.xml"/>
        
    </session-factory>
</hibernate-configuration>

oscache.properties

cache.capacity=1000
cache.algorithm=com.opensymphony.oscache.base.algorithm.LRUCache

TestModel.hbm.xml

<hibernate-mapping>
    <class name="ru.naumen.regservice.TestModel" table="model">
        <cache usage="read-write" />
        <id name="id" type="int" column="id">
             <generator class="native"/>
        </id>
        <property name="value" type="string" length="1000" />
        <property name="is_archive" type="int" />
    </class>
</hibernate-mapping>

public class TestHService implements ITest {

    public Integer addElem(String value) throws Exception
    {
        Session session = HibernateUtil.currentSession();
        TestModel model = new TestModel();
        model.setValue(value);
        session.save(model);
        return model.getId();
    }

    public TestModel getElem(Integer id) throws Exception
    {
        Session session = HibernateUtil.currentSession();
        Query query = session.createQuery("select obj from TestModel as obj where obj.id = :id");
        query.setInteger("id",id);
        List result = query.list();

        if(result.size()==1)
        {
            for(Object obj : result)
                return (TestModel)obj;
        }
        return null;
    }

    public List<TestModel> getList() throws Exception
    {
        Session session = HibernateUtil.currentSession();
        Query query = session.createQuery("select obj from TestModel as obj where is_archive = :is");
        query.setInteger("is",0);
        List<TestModel> result = new ArrayList<TestModel>();
        for(Object obj : query.list())
            result.add((TestModel)obj);
        return result;
    }

     public void setElem(TestModel model)  throws Exception
     {
        Session session = HibernateUtil.currentSession();
        session.save(model);
     }

    public void deleteElem(Integer id) throws Exception
    {
       Session session = HibernateUtil.currentSession();
       TestModel model = getElem(id);
       model.setIs_archive(1);
       session.save(model);
    }
}

------------------------------
специфичное для ibatis

SqlMapConfig.xml

<sqlMapConfig>
    <properties resource="SqlMapConfig.properties"/>
    <settings
            cacheModelsEnabled="true"
            enhancementEnabled="true"
            lazyLoadingEnabled="true"
            maxRequests="32"
            maxSessions="10"
            maxTransactions="5"
            useStatementNamespaces="false"
            />
    <typeAlias alias="order" type="testdomain.Order"/>
    <transactionManager type="JDBC">
        <dataSource type="SIMPLE">
            <property name="JDBC.Driver" value="${driver}"/>
            <property name="JDBC.ConnectionURL" value="${url}"/>
            <property name="JDBC.Username" value="${username}"/>
            <property name="JDBC.Password" value="${password}"/>
        </dataSource>
    </transactionManager>
    <sqlMap resource="TestModel.xml"/>
</sqlMapConfig>

TestModel.xml

<sqlMap namespace="TestModel">
    <cacheModel id="testModelCache" type="LRU">
        <flushInterval minutes="10"/>
        <property name="size" value="1000" />
        <flushOnExecute statement="insertTestModel"/>
        <flushOnExecute statement="updateTestModel"/>
        <flushOnExecute statement="deleteTestModel"/>
    </cacheModel>

    <typeAlias alias="test" type="ru.naumen.regservice.TestModel" />

    <resultMap id="all-result" class="test">
        <result property="id" column="id"/>
        <result property="value" column="value"/>
        <result property="is_archive" column="is_archive"/>
    </resultMap>

    <select id="getId" resultClass="int">
        SELECT nextval('test_gen'::regclass) AS newid
    </select>

    <select id="getTestModel" resultClass="test" parameterClass="int" cacheModel="testModelCache">
        SELECT id, value, is_archive FROM model WHERE id = #value#
    </select>

    <insert id="insertTestModel" parameterClass="test">
        INSERT INTO model (id, value) VALUES (#id#, #value#)
    </insert>

    <update id="updateTestModel" parameterClass="test">
        UPDATE model SET value = #value# WHERE id = #id#
    </update>

    <delete id="deleteTestModel" parameterClass="int">
        UPDATE model SET is_archive = 1 WHERE id = #value#
    </delete>

    <select id="getAll" resultMap="all-result" parameterClass="int" cacheModel="testModelCache">
        SELECT id, value, is_archive FROM model WHERE is_archive = #value#
    </select>
</sqlMap>

public class TestService implements ITest {
    public Integer addElem(String value) throws Exception
    {
        Integer id = (Integer)Starter.getSqlMap().queryForObject("getId",null);
        TestModel model = new TestModel();
        model.setId(id);
        model.setValue(value);
        Starter.getSqlMap().insert("insertTestModel",model);
        return id;
    }

    public TestModel getElem(Integer id) throws Exception
    {
        if(id==null)
            return null;
        return (TestModel) Starter.getSqlMap().queryForObject("getTestModel",id.intValue());
    }

    public List<TestModel> getList() throws Exception
    {
        List<TestModel> ret = (List<TestModel>)Starter.getSqlMap().queryForList("getAll", new Integer(0));
        return ret;
    }

    public void setElem(TestModel model)  throws Exception
    {
        if(model!=null)
            Starter.getSqlMap().update("updateTestModel", model);
    }

    public void deleteElem(Integer id) throws Exception
    {
        if(id!=null)
            Starter.getSqlMap().delete("deleteTestModel",id.intValue());
    }

Здравствуйте, Alex EXO, Вы писали:

AE> Если у ibatis и hibernate настроить кеш так, чтобы совпал объем занимаемой памяти, то hibernate пригрывает в 3-4 раза. Если дать hibernate кешь такой, что в него влазит вся тестовая база, то разрыв сокращается до 2 раз (но это в практике малореальный случай).

Меня вот какой вопрос всегда интересовал: насколько целесообразно использование кэширования в приложении вообще? Если взять, скажем, iBatis и прогнать его сперва с кэшем, а потом без оного, на выборке хорошего размера, каков будет выигрыш?

Здравствуйте, slskor, Вы писали:

S>Здравствуйте, Alex EXO, Вы писали:
S>Меня вот какой вопрос всегда интересовал: насколько целесообразно использование кэширования в приложении вообще? Если взять, скажем, iBatis и прогнать его сперва с кэшем, а потом без оного, на выборке хорошего размера, каков будет выигрыш?

Выигрыш будет и при малом количестве, просто потомуу, что часть обращений вообще не уйдет в базу.
Хотя бы на протоколе обмена (если в ДБ все в кеше) ито выигрыш будет...