Свой взгляд на изменения в образовании

Я уже слышал много разных мнений о том, какое должно быть образование в нашей стране. Лично я имею опыт на нескольких кафедрах, правда одного и того же факультета. Учился я на бакалавра, что сейчас является довольно редким явлением. А сейчас продолжаю учиться на магистра.

Форма обучения бакалавр-магистр лучше отражает реалии рынка, чем один специалист, т.к. люди быстрее оканчивают обучение и начинают работать. При том в результате бакалавр имеет тот же набор реальных знаний, что и специалист. Фактически, специалист полгода пишет диплом и сдает ГОСы. Получается, что учится он лишь на полгода больше бакалавра и изучает при этом предметы, имеющие узкую направленность(типа, AI). На 3-4 курсе толковые студенты, как правило, ищут(и находят) себе работу. Получается, что времени на учебу у него не остается. А пар у специалистов, как правило, много (2-4 в день). Соответственно, на 3-4 курсе человек уже физически не сможет учиться на полную. Бакалавр же как раз на 4 курсе заканчивает своё обучение и продолжает работать. Вместо этого, специалист учится ещё один напряженный год, со сдачей ГОСов и диплома и при этом ещё работает. Про тех же, кто не учится толком и не работает(и не пытается найти работу или приработок), можно сказать, что они просто оболтусы, сидящие на чужой шее. В 20 лет пора уже становится самостоятельными. При нынешнем качестве образования, разницы между бакалавром и спецом нет(в большинстве случаев). Фундаментальные предметы все проходят на 1-2 курсах. При том, за рубежом в большинстве стран нет понятия "Специалист", поэтому такие дипломы там приравниваются или к бакалавру или к магистру. Потом же бакалавр идет учиться на магистра, где совсем немного пар(около 5-6 в неделю, т.е. учишься например в пятницу и субботу). В магистратуре нет гуманитарных предметов и ничего не отвлекает от хорошего изучения сложных вопросов. Вообще предметов мало, но это хорошо, т.к. есть возможность качественно их изучить. Народ пока ещё не осознал нужно ли ему идти на магистра или нет. То есть на западе на магистра идут только если хотят приобрести какие-то серьезные познания в IT. А у бывает, идут потому что не знают, что им дальше делать. То есть примерно так это выглядит: отучился, работу на нашел, знаний толком не приобрел, надо бы ещё пойти поучиться. Но такого относительно мало и выбор в сторону магистратуры делается сознательно.

Лучше самому выбирать большинство предметов, чем доверить этот выбор другому. Скоро уже будет осуществлен переход на индивидуальные учебные планы и люди смогут сами выбирать часть предметов для освоения. Я считаю, что это очень хорошо. Студенту нужно давать выбор, давать возможность управлять своим обучением. Часто возникают вопросы и недоумения "Зачем мне поставили этот предмет?" или "Я не хочу изучать данный предмет у этого преподавателя". Ситуации бывают разные, бывает, что человеку просто сложно или некогда осилить все предметы и для более качественного обучения, он вынужден убрать лишние. Такое может быть полезно для людей, которые уже работают. Бывает, что предмет ведет человек, сам в нем не разбирающийся и ходить на него смысла никакого нет. Бывает, что предмет излишне жестко спрашивают и ты сам понимаешь, что не сможешь выучить 100 определений и 50 доказательств. Если ты соглашаешься изучать данный предмет, то ты заранее понимаешь на что идешь. Но если ты понимаешь, что не осилишь и не хочешь списывать, то просто отказываешься от него. Тем более в жестком учебном плане может не быть некоторых предметов предметов, интересных тебе или, которые ведет талантливый преподаватель.

Hibernate кэширование на практике и заключение (Ч5)

это перевод Hibernate in Action главы 5 
Hibernate транзакции, параллельность и кэширование. Основы транзакций. (Ч1) 
Очистка сессии, уровни изоляции транзакций, выбор и установка уровня изоляции транзакций в Hibernate (Ч2)
Пессимистическая и оптимистическая блокировки, транзакции приложения, версионирование, детализация сессии (Ч3) 
Кэширование в Hibernate (Ч4) 


5.3.3 Кэширование на практике
Помните, что вам не нужно явно разрешать кэш первого уровня. Итак, давайте объявим политику кэширования и установим поставщиков КЭШа для КЭШа второго уровня, в нашем приложении CaveatEmptor.
    Класс Category имеет малое количество экземпляров и обновляется редко, и экземпляры распределены среди многих пользователей, так что это отличный кандидат для использования КЭШа второго уровня. Мы начнем с добавления отображаемого элемента, это необходимо для того, чтобы сказать Hibernate, что нужно кэшировать экземпляры Category:

<class
name="Category"
table="CATEGORY">
<cache usage="read-write"/>
<id ....
</class>

Атрибут usage=”read-write” говорит Hibernate использовать стратегию параллелизма чтения-записи для КЭШа Category. Hibernate будет теперь пробовать достать запись из КЭШа второго уровня, когда мы перейдем на Category или, когда мы загрузим Category по идентификатору.
    Мы выбрали чтение-запись заместо нестрогой-чтения-записи, так как класс Category интенсивно используется одновременно, распределяется среди большого количества одновременных транзакций, и становится понятно, что уровень изоляции чтения зафиксированного  является достаточно хорошим. Однако, нестрогое-чтение-запись, вероятно, будет приемлимой альтернативой, поскольку существующая небольшая вероятность несоответствия между КЭШем и БД приемлема (иерархия категорий имеет малый финансовый смысл).
    Этого отображения было достаточно, чтобы сказать Hibernate кэшировать  все простые значения свойств, но не ассоциации или коллекции. Коллекции требуют своего <cache> элемента. Для коллекции items, мы используем стратегию чтение-запись:

<class
name="Category"
table="CATEGORY">
<cache usage="read-write"/>
<id ....
<set name="items" lazy="true">
<cache usage="read-write"/>
<key ....
</set>
</class>

Этот кэш будет использован, когда мы вызываем, например, category.getItems().iterate().
    Теперь кэш коллекции хранит только идентификаторы ассоциированных экземпляров элементов. Так, что если мы требуем закэшировать сами экземпляры элементов, то мы должны включить кэширование в классе Item. Стратегия чтения-записи здесь особенно уместна. Наши пользователи не хотят принимать решение (размещая ставки), основанные на возможно устаревших данных. Давайте пойдем ещё дальше и рассмотрим коллекцию ставок. В частности ставка и коллекции ставок является неизменяемой, но мы отметили коллекцию, используя чтение-запись, так как новые ставки могут быть сделаны в любое время (важно сразу же быть в курсе новых предложений):

<class
name="Item"
table="ITEM">
<cache usage="read-write"/>
<id ....
<set name="bids" lazy="true">
<cache usage="read-write"/>
<key ....
</set>
</class>
Для класса неизменяемой ставки, мы применим стратегию только-для-чтения:
<class
name="Bid"
table="BID">
<cache usage="read-only"/>
<id ....
</class>

Кэшированная ставка является верной всегда, поскольку ставки никогда не обновляются. Условия на недействительность КЭШа не требуются (экземпляры могут быть удалены из поставщика КЭШа, например, если достигнуто максимально количество объектов в КЭШе).
    Пользователь является примером класса, который может быть помещен в кэш нестрого-чтения-записи, но мы не уверены, что кэширование пользователей имеет смысл.
    Давайте установим поставщика КЭШа, политику истечения срока, а также физические свойства нашего КЭШа. Мы используем регионы кэша для настройки класса и кэширование коллекций в индивидуальном порядке.

Понимание регионов КЭШа
Hibernate хранит разные классы/коллекции в различных регионах КЭШа. Регион – это именованный кэш: указатель, на который вы можете ссылать классы и коллекции в настройке поставщика конфигурации и устанавливать политику срока вытеснения, применимую к этому региону.
    Имя региона является именем класса, в случае если это кэш класса; или имя класса с именем свойства, в случае КЭШа коллекций. Экземпляры Category кэшируются в регионе с именем org.hibernate.auction.Category и элементы коллекции кэшируются в регионе с именем org.hibernate.auction.Category.items.
    Вы можете использовать конфигурационный параметр hibernate.cache.region_prefix для указания названия корневого региона для конкретной SessionFactory. Например, если префикс был установлен в node1, категория будет закэширована в регионе с именем node1.org.hibernate.auction.Category. Эта опция полезна, если ваше приложение содержит несколько экземпляров SessionFactory.
    Теперь, когда вы знаете о регионах КЭШа, давайте настроим политику сроков вытеснения для КЭШа категорий. Сначала мы выберем поставщика КЭШа. Предположим, что мы запускаем наш аукцион на одной JVM, поэтому нам не нужна кластерно-безопасная реализация (которая бы ограничила наши возможности).

Установка локального поставщика КЭШа
Нам нужно установить свойство, которое выбирает поставщика КЭШа:

hibernate.cache.provider_class=net.sf.ehcache.hibernate.Provider

Мы выбрали EHCache, в качестве нашего кэша второго уровня.
    Теперь нам необходимо определить политику вытеснения для регионов КЭШа. EHCache имеет собственный конфигурационный файл, ehcache.xml в пути классов приложения. Hibernate поставляется с примерами конфигурационных файлов для всех встроенных поставщиков КЭШа, поэтому мы рекомендуем использовать комментарии в этих файлах для подробностей и принять варианты по умолчанию для всех опций, которые мы не указываем в явном виде.
    Конфигурация КЭШа в ehcache.xml для класса категорий может выглядеть следующим образом:

<cache name="org.hibernate.auction.model.Category"
maxElementsInMemory="500"
eternal="true"
timeToIdleSeconds="0"
timeToLiveSeconds="0"
overflowToDisk="false"
/>

Существует небольшое количество экземпляров категорий, и все они распределяются среди большого количества одновременных транзакций. Поэтому мы отключим вытеснение по таймауту, выбрав размер ограничения КЭШа больше, чем число категорий в нашей системе, устанавливая eternal=”true”. Нет необходимости в истечении срока действия данных КЭШа по тайм-ауту, потому что категории кэшируются используя стратегию чтения-записи, и потому что не других приложений, изменяющих данные категории. Мы также запретим кэширование на диске, поскольку мы знаем, что есть только несколько экземпляров категорий и что потребление памяти не будет проблемой.
    Ставки, с другой стороны являются небольшими и неизменными, но их много; поэтому мы должны настроить EHCache для аккуратного выделения кэш-памяти. Мы используем и тайм-аут и максимальный размер КЭШа:

<cache name="org.hibernate.auction.model.Bid"
maxElementsInMemory="5000"
eternal="false"
timeToIdleSeconds="1800"
timeToLiveSeconds="100000"
overflowToDisk="false"
/>

Атрибут timeToIdle определяет время вытеснения в секундах, с момента последнего доступа к элементу в кэше. Мы должны установить разумные значения здесь, поскольку мы не хотим, чтобы неиспользуемые ставки потребляли память. Атрибут timeToLiveSeconds определяет максимальное время вытеснения в секундах, с момента, когда элемент был добавлен в кэш. Поскольку ставки остаются неизменными, мы не должны удалять их из КЭШа, если к ним обращаются регулярно. Следовательно, атрибуту timeToLiveSeconds установлено большое число.
    Результатом является то, что кэшированные ставки будут удалены из КЭШа, если они не были использованы в течение последних 30 минут или если они наименее используемый элемент, если общий размер кэш-памяти достиг своего максимального предела в 5000 элементов.
    Мы отключили дисковый кэш в этом примере, так как мы ожидаем, что сервер приложений будет развернут на том же компьютере, что и БД. Если ожидаются различные физические архитектуры, то мы могли бы включить дисковый кэш.
    Оптимальная политика вытеснения из КЭШа, как вы видите, специфична для конкретных данных и особенностей применения. Вы должны учитывать множество внешних факторов, в том числе количество доступной памяти на компьютере, сервере приложений, ожидаемой нагрузки на БД компьютера, сетевые задержки, существование внешних приложений и т.д. Некоторые из этих факторов не могут быть известны во время разработки, поэтому вам часто приходится итеративно испытывать эффективность воздействия различных параметров окружения в реальных условиях или, симулируя эти условия.
    Это особенно верно в более сложных сценариях, с репликаций кэша, развернутого на кластере серверов.

Установка реплицируемого КЭШа
EHCache – это отличный поставщик КЭШа, если ваше приложение развертывается на одной виртуальной машине. Однако, корпоративному приложению поддерживающему тысячи одновременных пользователей, может потребоваться больше вычислительной мощности, и масштабирование приложения может иметь решающее значение для успеха вашего проекта. Hibernate приложения являются естественно масштабируемыми, то есть Hibernate ведет себе также, если он развернут на одной машине или на нескольких. Единственная особенность Hibernate, которая должна быть настроена специально для кластерных операций – это кэш второго уровня. Благодаря нескольким изменениям в нашей конфигурации КЭШа, мы можем использовать кластерные системы кэширования.
    Это не обязательно плохо использовать использовать чисто локального (не кластерного) поставщика КЭШа в кластере. Некоторые данные, особенно неизменяемые данные, или данные которые могут обновлены по тайм-ауту КЭШа – не требуют кластерного подтверждения и могут быть безопасно кэшированы локально, даже в кластерной среде. Мы могли бы установить каждому узлу в кластере использование локального EHCache, и тщательно выбирать достаточно короткий timeToLiveSeconds тайм-аут.
    Однако, если вам необходимо строгое состояние КЭШа в кластерной среде, то мы должны использовать более сложного поставщика КЭШа. Мы рекомендуем JBossCache, полностью транзакционную, кластерно-безопасную систему кэширования, основанную на JGroups библиотеке. JBossCache чрезвычайно производительный, и кластерная коммуникация может быть настроена любым воображаемым способом.
    Мы сейчас пошагово настроим JBossCache для CaveatEmptor для небольшого кластера из двух узлов: узел А и узел Б. Однако, мы только дотронемся до темы очень поверхностно; кластерные конфигурации по своей природе являются сложными, и многие параметры зависят от конкретного сценария.
    Во-первых, мы должны проверить, что все наши отображающие файлы используют только стратегии кэша только-для-чтения или транзакционную. Это единственные стратегии, поддерживаемые JBossCache поставщиком. Красивым приемом, которые поможет нам избежать проблемы поиска и замены в будущем: заместо размещения <cache> элементов в наших файлах отображения, мы централизовать конфигурацию КЭШа в hibernate.cfg.xml:

<hibernate-configuration>
<session-factory>
<property .../>
<mapping .../>
<class-cache
class="org.hibernate.auction.model.Item"
usage="transactional"/>
<collection-cache
collection="org.hibernate.auction.model.Item.bids"
usage="transactional"/>
</session-factory>
</hibernate-configuration>

Мы включили транзакционное кэширование для Item и для коллекции ставок в нашем примере. Однако есть важная оговорка: на момент написания этой книги, Hibernate вступит в конфликт, если у вас также есть <cache> элементы в файлах отображения.  Поэтому мы не можем использовать глобальную конфигурацию, чтобы переопределить параметры в файле конфигурации. Мы рекомендуем вам использовать централизованную конфигурацию КЭШа с самого начала, особенно если вы не уверены, как приложение может быть развернуто. Это также облегчает настройку параметров КЭШа.
    Следующим шагом в настройке кластера – это настройка конфигурации поставщика JBossCache. Во-первых мы включим его в Hibernate конфигурации, например, если  мы не используем свойства в hibernate.cfg.xml:

<property name="cache.provider_class">
net.sf.hibernate.cache.TreeCacheProvider
</property>

JBossCache имеет свой собственный файл конфигурации, treecache.xml, который ожидается в пути класса вашего приложения. В большинстве случаев, вам понадобится другая конфигурация для каждого узла кластера, и вы должны убедиться, что нужные файл копируется в путь класса при развертывании.  Давайте взглянем на типичный конфигурационный файл. В нашем кластере из двух узлов (названным MyCluster), этот файл используется на узле А:

<?xml version="1.0" encoding="UTF-8"?>
<server>
<classpath codebase="./lib"
archives="jboss-cache.jar, jgroups.jar"/>
<mbean code="org.jboss.cache.TreeCache"
name="jboss.cache:service=TreeCache">
<depends>jboss:service=Naming</depends>
<depends>jboss:service=TransactionManager</depends>
<attribute name="ClusterName">MyCluster</attribute>
<attribute name="CacheMode">REPL_SYNC</attribute>
<attribute name="SyncReplTimeout">10000</attribute>
<attribute name="LockAcquisitionTimeout">15000</attribute>
<attribute name="FetchStateOnStartup">true</attribute>
<attribute name="EvictionPolicyClass">
org.jboss.cache.eviction.LRUPolicy
</attribute>
<attribute name="EvictionPolicyConfig">
<config>
<attribute name="wakeUpIntervalSeconds">5</attribute>
<!-- Cache wide default -->
<region name="/_default_">
<attribute name="maxNodes">5000</attribute>
<attribute name="timeToIdleSeconds">1000</attribute>
</region>
<region name="/org/hibernate/auction/model/Category">
<attribute name="maxNodes">500</attribute>
<attribute name="timeToIdleSeconds">5000</attribute>
</region>
<region name="/org/hibernate/auction/model/Bid">
<attribute name="maxNodes">5000</attribute>
<attribute name="timeToIdleSeconds">1800</attribute>
</region>
</config>
</attribute>
<attribute name="ClusterConfig">
<config>
<UDP bind_addr="192.168.0.1"
ip_mcast="true"
loopback="false"/>
<PING timeout="2000"
num_initial_members="3"
up_thread="false"
down_thread="false"/>
<FD_SOCK/>
<pbcast.NAKACK gc_lag="50"
retransmit_timeout="600,1200,2400,4800"
max_xmit_size="8192"
up_thread="false" down_thread="false"/>
<UNICAST timeout="600,1200,2400"
window_size="100"
min_threshold="10"
down_thread="false"/>
<pbcast.STABLE desired_avg_gossip="20000"
up_thread="false"
down_thread="false"/>
<FRAG frag_size="8192"
down_thread="false"
up_thread="false"/>
<pbcast.GMS join_timeout="5000"
join_retry_timeout="2000"
shun="true" print_local_addr="true"/>
<pbcast.STATE_TRANSFER up_thread="true"
down_thread="true"/>
</config>
</attribute>
</mbean>
</server>

Конечно, этот файл конфигурации на первый взгляд может выглядеть страшно, но он легок для понимания. Вы должны знать, что это не только файл конфигурации для JBossCache, это много всего в одном: конфигурация JMX службы JBoss развертывания, файл конфигурации для TreeCache и детализированная конфигурация JGroups, коммуникационной библиотеки.
    Давайте, проигнорируем первые несколько строк, связанные с разрвертыванием JBoss (они будут игнрорироваться при запуске JBossCache вне сервера приложений JBoss) и посмотрим на Tree-Cache конфигурационные атрибуты. Эти настройки определяют реплицируемый кэш, который использует синхронизированные связи. Это означает, что узел передачи сообщений репликации ждет, пока все узлы в группе признают сообщение. Это хороший выбор для использования в по-настоящему реплицирующемся кэше. Асинхронная неблокирующая связь может быть более уместна, если узел Б был горячей заменой (узел, который немедленно берет на себя, если узел А сломался), вместо живого партнера. Горячая замена используется, когда целью является построение отказоустойчивого кластера, а не пропускная способность. Другие атрибуты конфигурации, такие как тайм-ауты, вместимость КЭШа, когда подсоединяется новый узел, ясны исходя из их названий.
    JBossCache предоставляет подключаемые политики вытеснения. В этом случае мы выбрали встроенную политику org.jboss.cache.eviction.LRUPolicy. Мы затем настроим вытеснение КЭШа для каждого региона, так же, как мы это делали с EHCache.
    Наконец, давайте посмотрим на конфигурацию взаимодействия JGroups кластеров. Порядок протоколов связи крайне важен, поэтому не меняйте или добавляйте строки в произвольном порядке. Наиболее интересным является первый протокол <UDP>. Мы связываем сокет с IP адресом 192.168.0.1 (IP адрес узла А в сети) и разрешаем многоадресную связь. Атрибут loopback должен быть установлен в истину, если узел А будет компьютером под управлением Microsoft Windows (это не так).
    Другие атрибуты JGroups являются более сложными и могут быть найдены в документации JGroups. Они имеют дело с алгоритмами, используемыми для обнаружения новых узлов в группе, обнаружение неисправностей и, в целом,  управления взаимодействием группы.
    Таким образом, после изменения стратегии параллельного кэширования ваших хранимых классов на транзакционную (или только-для-чтения) и создания treecache.xml файла для узла А, вы можете запустить ваше приложение и проверить выходной лог. Мы рекомендуем включить регистрацию в журнале отладки для org.jboss.cache класса, вы увидите, как JBossCache считывает конфигурацию, и узел А сообщает о первом узле в кластере. Для развертывания узла Б, измените IP адрес в конфигурационном файле и повторите процедуру развертывания с новым файлом. Вы должны увидеть сообщение о присоединении от обоих узлов, как только начнется использование транзакционного кэширования в кластере: каждый элемент, помещаемый в кэш, будет реплицирован, и обновляемые элементы будут признаны недействительными.
    Существует одна окончательная дополнительная настройка для рассмотрения. Для кластерных поставщиков КЭШа, возможно, было бы лучше установить опцию Hibernate конфигурации hibernate.cache.use_minimal_puts в истину(true). Когда этот параметр включен, Hibernate будет только добавлять элементы в кэш после проверки на то, что они уже не находятся в КЭШе. Эта стратегия работает лучше, если кэш пишет (получает) более интенсивно, чем читает (получает). Это вариант для реплицируемого КЭШа в кластере, но не для локального КЭШа (по умолчанию, параметр выставлен в false для оптимизации локального КЭШа). Используете ли вы кластерный или локальный кэш, вам иногда необходимо, контролировать это программно для тестирования или настройки.

Контролирование КЭШа второго уровня
Hibernate имеет несколько полезных методов, которые помогут вам испытать и настроить ваш кэш. Вы можете удивиться тому, как отключить кэш второго уровня полностью. Hibernate будет загружать поставщика КЭШа и начинать использовать кэш второго уровня, если у вас объявление КЭШа в ваших файлах отображения или конфигурационном XML файле. Если вы закомментируете их, то кэш отключен. Это является ещё одной веской причиной предпочитать централизованную конфигурацию КЭШа в hibernate.cfg.xml файле.
    Подобно тому, как сессия предоставляет методы для контроля КЭШа первого уровня программным способом, также SessionFactory предоставляет их для КЭШа второго уровня.
    Вы можете вызвать evict(), чтобы удлаить элемент из КЭШа, указав класс и идентификатор объекта:

SessionFactory.evict( Category.class, new Long(123) );

Вы также можете вытеснить все элементы некоторого класса или только особые роли:

SessionFactory.evict("org.hibernate.auction.model.Category");

Вы редко будете нуждаться в этих механизмах контроля.

5.4 Резюме
Эта глава была посвящена контролю одновременного выполнения и кэширования данных.
Вы узнали, что за одну единицу работы, либо все операции должны быть полностью успешны или целиком должны быть неуспешными (и изменения откачены назад). Это привело нас к понятию транзакции и ACID атрибутах. Транзакция атомарно оставляет данные в целостном состоянии и изолированными от одновременно выполняемых транзакций, и у вас есть гарантия, что данные, сделанные транзакцией долговечны.
    Вы используете два понятия транзакции в Hibernate приложениях: короткие транзакции БД и длинные транзакции приложения. Как правило, вы изоляцию уровня чтения подтвержденного для транзакций БД, вместе с оптимистически контролем параллелизма (проверка версий и временных меток) для длинных транзакций приложения. Hibernate значительно упрощает реализацию транзакций приложения, поскольку он управляет номером версий и временными метками.
    Наконец, мы обсудили основы кэширования, и вы узнали, как использовать кэширование эффективно в Hibernate приложениях.
    Hibernate предоставляет двухслойную систему кэширования с первым уровнем КЭШа (сессия) и подключаемым КЭШем второго уровня. Кэш первого уровня активен всегда – он используется для разрешения циклических ссылок в вашем графе объектов и для оптимизации производительности на одну единицу работы. (Процессный или кластерный) Кэш второго уровня с другой стороны является опциональным и лучше всего подходит для классов, которые в основном считываются. Вы можете настроить неизменяемый кэш второго уровня для справочных (только-для-чтения) данных, или кэш второго уровня с полной транзакционной изоляцией важных данных. Однако, вы должны внимательно изучить стоит ли прирост производительности усилий. Кэш второго уровня может быть детально настроен для каждого хранимого класса, и для каждой коллекции и ассоциации. Правильно и тщательно протестированное кэширование в Hibernate даст вам уровень производительности, который почти не достижим в написанных самостоятельно слоях доступа к данным.

Кэширование в Hibernate (Ч4)

это перевод Hibernate in Action главы 5 
Hibernate транзакции, параллельность и кэширование. Основы транзакций. (Ч1) 
Очистка сессии, уровни изоляции транзакций, выбор и установка уровня изоляции транзакций в Hibernate (Ч2)
Пессимистическая и оптимистическая блокировки, транзакции приложения, версионирование, детализация сессии (Ч3) 
 
5.3 Теория и практика кэширования
Основным обоснованием нашего утверждения является то, что приложения, использующие объектно-реляционный слой, как ожидается, превосходят приложения, построенные с использованием прямого JDBC, благодаря возможности кэширования. Хотя мы будем утверждать, что самые странные заявления должны быть сконструированы таким образом, что возможно достигнуть приемлемой производительности без использования КЭШа, нет никаких сомнений, что для некоторых видов приложений – особенно приложения, осуществляющие в основном чтения или приложения, сохраняющие значительные метаданные в БД – кэширование может иметь огромное влияние на производительность.
    Мы начнем наше исследование кэширования с некоторой справочной информации. Она включает в себя объяснение различия кэширования и идентичности областей, и влияния кэширования на изоляцию транзакций. Эта информация, и эти правила могут применяться для кэширования в общем; они применимы не только для Hibernate приложений. Эта дискуссия дает основу для понимания, почему система кэширования в Hibernate такая, какая она есть. Затем, мы введем вас в систему кэширования Hibernate и покажем вам, как включить настройки и управлять КЭШем Hibernate первого и второго уровня. Мы рекомендуем вам внимательно изучить основы, изложенные в этом разделе, прежде, чем начать использование кэш-памяти. Без основы, вы можете быстро заиметь сложные в отладки проблемы одновременной доступности и риски целостности ваших данных.
    Кэш-память хранит представление текущего состояния БД для приложения, либо в памяти или на диске компьютера сервера приложения. Кэш – это локальная копия данных. Кэш находится между приложением и БД. Кэш может использоваться, чтобы избежать обращений к БД, когда:
•    Приложение выполняет поиск по идентификатору (первичному ключу)
•    Хранимый слой разрешает ленивую ассоциацию
Также возможно, кэшировать результаты запросов. Как вы увидите, в главе 7, прирост производительности кэширования запросов минимален, большинстве случаев это так, так что эта функция используется гораздо реже.
    Прежде, чем мы рассмотрим, как работает Hibernate кэш, давайте рассмотрим различные параметры кэширования и посмотрим, как они относятся к идентичности и параллелизму.

5.3.1 Стратеги кэширования и области
Кэширование является настолько фундаментальным понятием в объектно-реляционном отображении, что вы не сможете понять производительность, масштабируемость или семантику транзакций в реализации объектно-реляционного отображения, без первоначальных представления какую стратегию (или стратегии) кэширования он использует. Существуют три основных типа КЭШа:
•    Транзакционный – связанный с текущей единицей работы, которая может быть фактическая транзакция БД или транзакция приложения. Она корректна и используется во время работы единицы работы. Каждая единица работы имеет свой кэш.
•    Процессный – распределяется между многими (возможно одновременными) единицами работы или транзакции. Это означает, что данные в процессном КЭШе доступны одновременно выполняемым операциям, очевидно с последствиями для изоляции транзакций. Процессный кэш может хранить хранимые объекты целиком в КЭШе, или может хранить их состояние в разобранном формате.
•    Кластерный – распределяется между несколькими процессами на одной машине или между несколькими машинами в кластере. Он требует какой-то удаленный процесс взаимодействия для поддержания согласованности. Кэширование информации должно быть продублировано на всех узлах кластера. Для многих (не всех) приложений, кластерное кэширование имеет сомнительную ценность, так как чтение и обновление КЭШа может быть лишь незначительно быстрее, чем прямое обращение в БД.
Хранимые слои могут обеспечивать несколько уровней кэширования. Например, промах КЭШа(cache miss) (поиск элемента в КЭШе, который там не содержится) в транзакционном типе может последовать за поиском в процессном. Запрос к БД будет последней инстанцией.
    Тип КЭШа, используемый хранимым уровнем, влияет на сферу идентичности объектов (взаимосвязь между Java идентичностью и идентичностью на уровне БД)

Кэширование и идентичность объектов
Рассмотрим транзакционный кэш. Кажется естественным, что этот кэш используется также для осуществление идентичности хранимых объектов. Это означает, что транзакционный кэш реализует обработку идентичности: два поиска, использующих один и тот же идентификатор БД, возвращают тот же Java объект в одной единице работы. Поэтому транзакционный кэш идеально подходит, если механизм сохранения также предоставляет транзакционную идентичность.
    Механизм сохранения с процессным КЭШем можно выбрать для реализации процессной идентификации. В этом случае, объект идентификации эквивалентен для БД для всего процесса. Два поиска, использующие один и тот же идентификатор БД в двух единицах одновременно выполняемой работы, вернут в результате один и тот же экземпляр Java. Кроме того, объекты извлекаются из процессного КЭШа, могут быть возвращены по значению. Кэш содержит кортежи данных, а не хранимые экземпляры. В этом случае, каждая единица работы загружает свою копию состояния(кортеж) и строит свой собственный хранимый объект. Объем кэш-памяти и объем идентичности объектов уже не являются одинаковыми.
    Кластерный кэш всегда требует удаленной связи, а в случае POJO-решений, таких как Hibernate, объекты всегда передаются удаленно по значению. Кластерный кэш не может гарантировать идентичность через кластер. Вы должны выбирать между транзакционной или процессной идентичностью объектов.
    Для типичной архитектуры Интернет или корпоративных приложений, самым удобным является, когда сфера идентичности объектов ограничивается одной единицей работы. Иными словами, это ни необходимо, ни желательно, иметь идентичными объекты в двух параллельных потоках. Существуют и другие виды приложений (в том числе некоторые настольные или толстый-клиент архитектуры), где была бы уместно использовать процессную идентичность объектов. Это особенно справедливо, когда память сильно ограничена – потребление памяти транзакционного кэша пропорционально количеству одновременных единиц работы.
    Недостатком процессной идентичности является необходимость синхронизации доступа к хранимым объектам в КЭШе, что приводит к высокой вероятности возникновения тупиков.

Кэширование и параллелизм
Любая реализация объектно-реляционного отображения, которая позволяет нескольким единицам работы разделять одни хранимые объекты, должна предоставлять некоторые формы блокировок на уровне объектов, для обеспечения синхронизации параллельного доступа.  Обычно, это реализуется, используя блокировки на чтение и запись (устанавливаемые в памяти) вместе с определением тупиков. Реализации, вроде Hibernate, которые поддерживают различных набор экземпляров для каждой единицы работы (транзакционная идентичность), избегают этих проблем в значительной степени.
    Наше мнение, что блокировок в памяти следует избегать, по крайней мере для веб-сайтов и корпоративных приложений, где многопользовательская масштабируемость является главной заботой. В этих приложений, обычно нет необходимости сравнивать объекты на идентичность в параллельных единицах работы; каждый пользователь  должен быть полностью изолирован от других пользователей.
    Существуют довольно веские аргументы в пользу этой точки зрения, когда реляционной  СУБД реализует модель многоверсионного параллелизма  (например, Oracle или PostgreSQL). Это несколько нежелательно для объектно-реляционного хранимого КЭШа, чтобы переопределять семантику транзакций или модель параллелизма нижележащей БД.
    Рассмотрим эту опцию снова. Транзакционный кэш является предпочтительным, если вы также можете использовать транзакционную идентичность объектов и это лучшая стратегия для высоко-параллельных многопользовательских систем. Этот первый уровень КЭШа будет обязательным, посколько он также гарантирует идентичность объектов. Однако, это единственный кэш, который вы можете использовать. Для некоторых данных, может быть полезен кэш второго уровня, относящийся к процессу (или кластеру), который возвращает данные по значению. Поэтому этот сценарий имеет два уровня КЭШа; вы позже увидите, что Hibernate использует этот подход.
    Давайте обсудим, какие преимущества есть от второго уровня кэширования, или, другими словами, когда для включать процессный (или кластерный) КЭШ второго уровня, в дополнении к обязательному КЭШу первого уровня.

Кэширование и изоляция транзакций
Процессный или кластерный кэш делают извлечение данных из БД в одной единице работы, видимой для другой единицы работы. Это может иметь очень неприятные эффекты, при изоляции транзакций.
    Во-первых, если приложение не имеет эксклюзивного доступа к БД, то процессное кэширование не должно использоваться, за исключением данных, которые редко меняются и могут быть безопасно обновлены по истечению срока кэширования. Этот тип данных часто встречается в приложениях, управляющих содержанием, но редко в финансовых приложениях.
    Вам нужно взглянуть на два основных сценария, с участием неэксклюзивного доступа:
•    Кластерные приложения
•    С общими данными
Любое приложение, задуманное для расширяемости, должно поддерживать кластерные операции. Процессный кэш не поддерживает согласованность между различными КЭШами на разных машинах в кластере. В этом случае вы должны использовать кластерный (распределенный) кэш вместо процессного КЭШа.
    Многие Java приложения разделяют доступ к своей БД с другими приложениями. В этом случае, вы не должны использовать любой тип КЭШа, кроме транзакционного кэша. Не существует никакой возможности для кэширующей системы, что знать когда совместное приложение обновило общие данные. Собственно, это можно реализовать на уровне приложения для показа недействительности процессного (или кластерного) КЭШа, когда изменения сделаны в БД, но мы не знаем какого-либо стандартного или лучшего пути достижения этой цели. Конечно, это никогда не будет встроенной возможностью Hibernate. Если вы реализуете такое решения, то оно, скорее всего подойдет только для вас, потому что оно сильно зависит от среды и используемых продуктов.
    После рассмотрения неэкслюзивного доступа к данным, вы должны установить, как уровень необходим для данных приложения. Не всякий кэш реализует все уровни изоляции транзакций и это критически важно узнать. Давайте посмотрим на данные, которые выгодны для процессного (или кластерного) КЭШа.
    Полное объектно-реляционное решение позволит вам настроить кэш второго кровня отдельно для каждого класса. Хорошими кандидатами на кэширования являются классы, которые представляют:
•    Данные, которые редко меняются
•    Не критичные данные
•    Данные, которые локальны для приложения и не являются общими
Плохими кандидатами для КЭШа второго уровня являются:
•    Данные, которые часто меняются
•    Финансовые данные
•    Данные, которые являются общими с другими приложениями
Однако, это не все правила, которые мы обычно применяем. Многие приложения имеют несколько классов, со следующими свойствами:
•    Маленькое количество экземпляров
•    На каждый экземпляр ссылается много других экземпляров другого класса или классов
•    Экземпляры редко (или никогда) обновляются
Такие данные иногда называют справочными данными. Справочные данные являются отличным кандидатом для кэширования процессным или кластерным КЭШем, и любое приложение, которое интенсивно использует  эти данные сильно выигрывает от того, что данные закэшированы. Вы позволяете данным обновляться во время истечение таймаута КЭШа.
    Мы сформировали картину двойного слоя системы кэширования в предыдущих разделах, с транзакционным КЭШем первого уровня и опциональным процессным или кластерным КЭШем второго уровня. Это похоже на систему кэширования Hibernate.

5.3.2 Архитектура КЭШа в Hibernate
Как мы говорили ранее, Hibernate имеет двухуровневую архитектуру кэш-памяти. Различные элементы этой системы можно увидеть на рис. 5.5
(РИС. 5.5)
Кэш первого уровня является также сессией. Жизненный цикл сессии соответствует либо транзакции БД, либо транзакции приложения (как описано ранее в этой главе). Мы считаем кэш, связанный с сессий транзакционным. Кэш первого уровня является обязательным и не может быть выключен; это также гарантирует идентичность объектов внутри транзакции.
    Кэш второго уровня в Hibernate является подключаемым и может быть процессным или кластерным. Это кэш состояний (возвращаемых по значению), а не хранимых экземпляров. Стратегия параллельности  КЭШа определяет детали транзакционной изоляции для определенных элементов данных, в то время, как поставщик КЭШа представляет собой физическую, фактическую реализацию КЭШа. Использование КЭШа второго уровня является необязательным и может быть настроено на каждый класс и на каждую ассоциацию.
    Hibernate также реализует кэширование результатов запросов, тесно интегрированных с КЭШем второго уровня. Это является дополнительной функцией. Мы обсуждаем кэш запросов в главе 7, так как его использование тесно связано с фактическим выполнением запросов.
    Давайте начнем с использования КЭШа первого уровня, который также называется КЭШем сессии.

Использование КЭШа первого уровня
Кэш сессии гарантирует, что когда приложение запросит такой же хранимый объект дважды в той же сессии, то он получит тот же (идентичный) Java экземпляр. Это иногда позволяет избегать ненужного трафика БД. Более важно, что он обеспечивает следующее:
•    Слой хранимых объектов не подвержен опасности переполнения стека, в случае циклических ссылок в графе объектов
•    Никогда не возникнет конфликтов представлений об одной строке БД в конце транзакции БД. Существует не более одного объекта, представляющего любую строку БД. Все изменения, внесенные в этот объект, могут быть безопасно записаны в БД (сброшены).
•    Изменения, сделанные в конкретной единице работы всегда незамедлительно видны всему другому коду, исполняемому внутри этой единицы работы.
Вам не нужно делать ничего специального для того, чтобы разрешить кэш сессии. Он всегда включен, и по указанным причинам, не может быть отключен.
Всякий раз, когда вы вызываете save(), update() или saveOrUpdate() и всякие раз, когда вы получаете объект, используя load(), find(), list(), iterate() или filter(), он добавляется в кэш сессии. Когда впоследствии вызывается flush(), то состояние объекта синхронизируется с БД.
    Если вы не хотите, чтобы эта синхронизация происходила, или если вы обрабатываете огромное количество объектов и необходимы эффективные средства управления памятью, то вы можете использовать метод evict() сессии, для удаления объекта и его коллекции из первого уровня кэш-памяти. Есть несколько сценариев, где это может быть полезно.

Управление КЭШем первого уровня
Рассмотрим этот часто задаваемый вопрос: «Я получаю OutOfMemoryException при попытке загрузить 100,000 объектов и манипулируя всеми ими. Как я могу сделать массовые обновления с Hibernate?».
    Наше мнение, что объектно-реляционное отображение не подходит для операций массового обновления (или удаления). Если у вас есть прецедент, как этот, то иная стратегия почти всегда лучше: вызов хранимой процедуры в БД или использование прямых SQL UPDATE и DELETE выражений. Не передавайте все данные в основную память для простых операций, если она может быть выполнена более эффективно в БД.
Если ваше приложение в основном использует массовые операции, то объектно-реляционного отображение не является правильным инструментом для работы!
Если вы настаиваете на использовании Hibernate для массовых операций, вы должны немедленно вызывать evict() каждого объекта, после того, как он будет обработан (при переборе результатов запроса), и тем самым предотвратить исчерпание памяти.
Чтобы полностью убрать все объекты из КЭШа первого уровня, вызовите Session.clear(). Мы не пытаемся убедить вас, что убранные объекты первого уровня является плохой вещью в целом, однако, редко встречаются хорошие случаи его использования. Иногда использование проекций и отчетных запросов, как это обсуждается в главе 7, раздел 7.4.5 «Повышение производительности с отчетными запросами», может быть лучшим решением.
Обратите внимание, что убирание, как и операции сохранения и удаления, могут автоматически применяться к ассоциированным объектам. Hibernate будет убирать ассоциированные экземпляры из сессии, если в файле отображения атрибуту cascade задано значение ”all” или “all-delete-orphan” для конкретной ассоциации.
Когда случается промах первого уровня КЭШа, Hibernate пытается взять значение из КЭШа второго уровня, если он включен для определенного класса или ассоциации.

Кэш второго уровня Hibernate
Hibernate кэш второго уровня является процессным или кластерным; все сессии обладают одним и тем же КЭШем второго уровня. Кэш второго уровня, на самом деле, имеет область SessionFactory.
Хранимые экземпляры хранятся в КЭШе второго уровня в разобранном виде. Думайте о демонтаже, как о процессе похожем на сериализацию (однако, алгоритм, намного, намного быстрее, чем Java сериализация).
Внутреннее представление этого процессного/кластерного КЭШа не представляет большого интереса; более важным является правильное использование политики кэширования, то есть стратегии кэширования и выбор физических провайдеров КЭШа.
Различные виды данных требуют различной политики кэширования: соотношение чтение к записи изменяется, размер БД изменяется, и  некоторые таблицы используются совместно с другими приложениями. Так что, кэш второго уровня настраиваемся под детализацию каждого индивидуального класса или коллекцию ролей. Это позволяет, например, разрешить кэш второго уровня для справочных данных и запретить его для классов, представляющих финансовые записи. Политика КЭШа включает в себя настройку следующих параметров:
•    Включен ли кэш второго уровня
•    Стратегию параллелизма Hibernate
•    Политика истекания срока кэширования (такую, как тайм-аут, LRU, зависимую от ОП)
•    Физическое устройство КЭШа (в памяти, индексируемые файлы, кластерная репликация)
Не все классы имеют выгоду от кэширования, поэтому чрезвычайно важно иметь возможность отключить кэш второго уровня. Повторяем, кэш-память, как правило полезно только для классов, которые по большинству считываются. Если у вас есть данные, которые обновляются чаще, чем читаются, не разрешайте кэш второго уровня, даже если все остальные условия для кэширования верны! Кроме того, кэш второго уровня может быть опасен в системах, которые разделяют данные с другими приложениями, которые могут эти данные изменить. Как мы объяснили в предыдущих разделах, необходимо тщательно подумать над решением.
    Hibernate кэш второго уровня устанавливается в два этапа. Во-первых, вы должны решить, какую стратегию параллельности использовать. После этого вам нужно настроить истечение КЭШа и физические атрибуты, используя поставщика КЭШа.



 Встроенные стратегии параллелизма
Стратегия параллелизма является посредником; она несет ответственность за хранение элементов данных в кэш памяти и извлечение их из КЭШа. Это важная роль, поскольку она определяет семантику изоляции транзакций для этого конкретного пункта. Вам придется принять решение по каждому хранимому классу, какую стратегию параллелизма кэша использовать, если вы хотите разрешить кэш второго уровня.
    Есть четыре встроенных стратегии параллелизма, представляющие снижение уровня строгости, в терминах изолированности транзакции:
•    Транзакционная – доступна только в управляемой среде. Она гарантирует полную изоляцию транзакций до повторяемого чтения, если это требуется. Используйте эту стратегию для данных которых в большинстве считываются, в которых очень важно предотвратить появление устаревших данных в параллельных транзакциях, в редких случаях обновления.
•    Чтение-запись – поддерживает изоляцию чтения подтвержденного, используя механизм временных меток. Она доступна только в некластерных средах. Опять же, использовать эту стратегию нужно для чтения данных, в которых очень важно предотвратить появление устаревших данных в параллельных транзакциях, в том редком случае обновления.
•    Нестрогое-чтение-запись -  не дает никакой гарантии согласованности между КЭШем и БД. Если есть возможность одновременного доступа к одной сущности, то вам необходимо настроить достаточно короткий срок истечения тайм-аута. В противном случае, вы можете прочитать устаревшие данные в КЭШе. Используйте эту стратегию, если данные редко меняются (несколько часов, дней или даже недель), и небольшая вероятность появления устаревших данных не является критической проблемой. Hibernate считает недействительным кэшируемый элемент, если модифицируемый объект очищается(flush), но это асинхронные операции, без какой-либо блокировки КЭШа или гарантии, что полученные данные являются последней версией.
•    Только-для-чтения – данная стратегия подходит для данных, которые никогда не меняются. Используйте её только для справочных данных.
Обратите внимание, что с уменьшением строгости приходит увеличение производительности. Вы должны тщательно оценивать эффективность кластерного КЭШа с полной изоляцией транзакций, перед тем как использовать его в реальных условиях. Во многих случаях, вам было бы лучше, отключить кэш второго уровня для конкретного класса, если устаревшие данные не приемлемы. В начале, протестируйте ваше приложение с отключенным КЭШем второго уровня. Тогда включайте его только для хороших классов-кандидатов, по одному, постоянно тестируя производительность вашей системы и оценивая стратегию параллелизма.
    Можно определить свою собственную стратегию, реализуя net.sf.hibernate.cache.CacheConcurrencyStrategy, но это довольно трудная задача и применяется только в крайне редких случаях  оптимизации.
    Вашим следующим шагом после выбора стратегий параллелизма, которые вы будете использовать для ваших кандидатов на кэширования, является выбор поставщиков КЭШа. Поставщик является подключаемым, физической реализаций системы кэширования.


Выбор поставщика КЭШа
Сейчас, Hibernate заставляет вас выбирать одного поставщика КЭШа для всего приложения. Следующие поставщики встроены в Hibernate:
•    EHCache предназначен для простого процессного кэширования в одной JVM. Он может кэшировать в памяти или на диске и поддерживает опциональный Hibernate кэш результатов запроса.
•    OpenSymfony OSCache – это библиотека, которая поддерживает кэширование в памяти и на диске в одной JVM, с богатым набором политик истечения и поддержкой КЭШа запросов.
•    SwarmCache – это кластерный кэш, основанный на JGroups. Он использует кластерное аннулирование, но не поддерживает кэш Hibernate запросов.
•    JBossCache – это полностью транзакционно-репликационный кластеризованный кэш, также основанных на JGroups. Кэш запросов Hibernate поддерживается, предполагая, что часы в кластере синхронизированы.
Легко написать адаптер для других продуктов, реализуя net.sf.hibernate.
cache.CacheProvider.
    Не каждый поставщик КЭШа совместим с каждой стратегией параллелизма. Матрица совместимости представлена в таблице 5.1 поможет вам выбрать соответствующую комбинацию.

Поставщик кэша	только-для-чтения	нестрогое-чтение-запись	чтение-запись	транзакционная
EHCache	x	x	x
OSCache	x	x	x
SwarmCache	x	x		x
JBossCache	x			x

Настройка кэширования включает в себя два этапа:
1.    Взгляните на файлы отображения ваших хранимых классов и решите, какую стратегию параллельного КЭШа вы хотели бы использовать для каждого класса и для каждой ассоциации.
2.    Включите предпочтительного поставщика КЭШа в глобальной конфигурации Hibernate и установите конкретные настройки поставщика.
Например, если вы используете OSCache, нужно отредактировать oscache.properties, или для EHCache ehcache.xml в ваших путях к классам(classpath).
    Давайте, добавим кэширование к нашему CaveatEmptor  Category и Item классам.

Hibernate кэширование на практике и заключение (Ч5)

Пессимистическая и оптимистическая блокировки, транзакции приложения, версионирование, детализация сессии (Ч3)

это перевод книги Hibernate In Action Глава 5
Hibernate транзакции, параллельность и кэширование. Основы транзакций. (Ч1) 
Очистка сессии, уровни изоляции транзакций, выбор и установка уровня изоляции транзакций в Hibernate (Ч2)

 5.1.7 Использование пессимистической блокировки

Блокировка – это механизм, который предотвращает одновременный доступ к конкретному объекту данных. Когда одна транзакция владеет блокировкой на элемент, то непараллельная транзакция может читать и/или изменять этот элемента. Блокировка может быть только моментальным замком, состоявшимся в том время, как элемент был прочитан, или он может состояться до тех пор пока транзакция не завершится. Пессимистическая блокировка – это блокировка, которая устанавливается при чтении элемента и удерживается до тех пор, пока транзакция не завершится.

    В режиме чтения подтвержденного (наш предпочтительный уровень изоляции транзакций), БД никогда не приобретает пессимистическую блокировку, если это явно не запрашивается приложением.  Как правило, пессимистические блокировки не являются самым масштабируемым подходом к параллелизму. Однако, при определенных обстоятельствах, они могут быть полезны для предотвращения тупиковых ситуаций на уровне БД, которые приводят к сбою транзакций. Некоторые СУБД (например, Oracle и PostgreSQL) обеспечивают SQL SELECT … FOR UPDATE синтаксис, чтобы разрешить использование явных пессимистических блокировок. Вы можете проверить Hibernate диалекты, чтобы узнать поддерживает ли ваша БД эту функцию. Если БД не поддерживает такой функции, то Hibernate будет всегда выполнять обычный SELECT без FOR UPDATE  пункта.

    Класс Hibernate LockMode позволяет запрашивать пессимистические блокировки на конкретный элемент. Кроме того, вы можете использовать LockMode, чтобы заставить Hibernate не использовать уровень КЭШа или выполнить простую проверку версии. Вы увидите выгоду этих операций, когда мы обсудим версионирование и кэширование.

Давайте взглянем на использование LockMode.  Если у вас есть транзакция, на подобии этой:

  Transaction tx = session.beginTransaction();
  Category cat = (Category) session.get(Category.class, catId);
  cat.setName("New Name");
  tx.commit();

тогда, вы можете установить пессимистичную блокировку следующим образом:
  Transaction tx = session.beginTransaction();
  Category cat = (Category) session.get(Category.class, catId, LockMode.UPGRADE);
  cat.setName("New Name");
  tx.commit();

В этом режиме, Hibernate будет загружать категории, используя SELECT … FOR UPDATE, таким образом, блокирую возвращаемые строки в БД, пока они не будут освобождены, когда транзакция завершится.

    Hibernate определяет несколько стратегий блокировок:

•    LockMode.NONE – не обращается к БД, за исключением случае, если объект не в КЭШе.

•    LockMode.READ – обходит оба уровня КЭШа, а также выполняет проверки версии, чтобы убедиться, что версия объекта в памяти совпадает с той, что существует в БД.

•    LockMode.UPGRADE – обходит оба уровня КЭШа, выполняет проверку версии (если применимо), и получает пессимистическую блокировку обновления уровня БД, если она поддерживается.

•    LockMode.UPGRADE_NOWAIT – тоже самое, что UPGRADE, но использует SELECT … FOR UPDATE NOWAIT в Oracle. Это отключает ожидание освобождения параллельных блокировок, тем самым выбрасывая исключение о блокировке немедленно, если блокировка не может быть получена.

•    LockMode.WRITE – устанавливается автоматически, когда Hibernate записывает строку в текущей транзакции (это внутренний режим; вы не можете указать это явно).

По умолчанию, load() и get() используют LockMode.NONE. LockMode.READ является наиболее полезным с Session.lock() и несвязанным объектом. Например:

  Item item = ... ;
  Bid bid = new Bid();
  item.addBid(bid);
  ...
  Transaction tx = session.beginTransaction();
  session.lock(item, LockMode.READ);
  tx.commit();

Этот код выполняет проверку версии на несвязанном Item для проверки того, что строка БД не обновлена другой транзакцией с момента её извлечения, перед сохранением нового Bid каскадно (предполагая, что каскадная ассоциация от Item к Bid разрешена).

    Задавая явный LockMode, отличный от LockMode.NONE, вы заставляете Hibernate обойти оба уровня КЭШа и пройти весь путь к БД. Мы считаем, что в большинстве случаев кэширование является более полезным, чем пессимистическая блокировка, поэтому мы не используем явный LockMode, если мы действительно в нем не нуждаемся. Наш совет в том, что если у вас есть профессиональный администратор БД на вашем проекте, то пусть администратор решит какие операции требуют пессимистических блокировок, как только приложение запущено и работает. Это решение должно зависеть от тонких деталей взаимодействия между различными операциями, о которых можно не догадаться сразу.

    Давайте рассмотрим ещё один аспект одновременного доступа к данным. Мы считаем, что большинство Java разработчиков знакомы с понятием транзакции БД, и это то, что они обычно имеют ввиду под транзакцией. В этой книге, мы полагаем, что это мелкозернистые(fine-grained) транзакции, но мы также полагаем более крупнозернистое понятие. Наши крупнозернистые транзакции будут соответствовать тому, что пользователь считает одной единицей работы. Почему они должны отличаться от мелкозернистых транзакций БД?

   БД изолирует воздействие параллельных транзакций БД. Она должна появиться в приложении, где каждая транзакция является единственной доступной транзакцией в настоящее время в БД (даже если это не так). Изоляция является дорогостоящей. БД должна выделять значительные ресурсы для каждой транзакции на время транзакции. В частности, мы уже обсуждали, что многие БД блокируют строки, которые были прочитаны или обновлены в транзакции, не допуская любые другие транзакции, до завершения первой транзакции. В системах с высокой степенью параллелизма, эти блокировки могут ухудшить масштабируемость, если они удерживаются дольше, чем это абсолютно необходимо. По этой причине, вы не должны удерживать транзакции БД (или даже JDBC соединений) открытых, в ожидании пользовательского ввода (все это разумеется также относится к Hibernate транзакции, поскольку это всего лишь адаптер к основном механизму транзакций БД).

    Если вы хотите работать с длительным ожиданием пользовательских действий, используя преимущества ACID транзакций, то простые транзакции БД не являются достаточными. Вам нужна новая концепция, длительные транзакции приложения.

5.2 Работа с транзакциями приложения

Бизнес-процессы, которые могут рассматриваться, как одна единица работы с точки зрения пользователя, обязательно охватывают несколько клиентских запросов. Это особенно справедливо, когда пользователь принимает решение об обновлении данных на основе текущего состояния этих данных.

    В крайнем примере, предположим, что вы собираете данные, введенные пользователем на нескольких экранах, возможно, с помощью пошагового мастера. Вы должны прочитать и записать соответствующие пункты данных в нескольких запросах (следовательно, несколько транзакций БД) пока пользователь не нажмет «Готово» на последней странице. На протяжении всего этого процессы, данные должны оставаться согласующимися и пользователь должен быть проинформирован о любых изменениях в данных, сделанных в любой параллельной транзакции. Мы называем это крупнозернистой концепцией транзакции приложения, более широкое понятие единицы работы.

    Мы сейчас переформулируем это определение точнее. Большинство веб-приложений включает в себя несколько примерно следующих типов функциональности.

1.    Данные извлекаются и отображаются на экране в первой транзакции БД.

2.    Пользователь имеет возможность просмотреть и изменить данные, вне всяких транзакций БД.

3.    Изменения сохраняются в БД во второй транзакции.

В более сложных приложения, это может быть несколько таких взаимодействий с пользователем до того, как конкретное бизнес-действие будет завершено. Это приводит к понятию транзакции приложения (иногда, называемое, длинные транзакции, пользовательская транзакция или бизнес транзакция). Мы предпочитаем понятие транзакция приложения или пользовательская транзакция, так как эти условия являются менее расплывчатыми и подчеркивают аспект транзакции с точки зрения пользователя.

    Поскольку вы не можете рассчитывать на БД для обеспечения изоляции (или даже атомарности) от параллельных транзакций приложения, изоляция становится заботой самого приложения, возможно даже озабоченностью пользователя.

    Давайте обсудим применение транзакций приложения на примере.

В нашем приложении CaveatEmptor, как пользователь может размещать комментарий, так и любой администратор может открыть экран редактирования комментариев, удалять или редактировать текст комментария. Предположим, что два разных администратора открыли экран редактирования, чтобы посмотреть один и тот же комментарий одновременно. Как изменить текст комментария и отобразить эти изменения. На данные момент, мы имеем три способа справиться с попыткой одновременной записи в БД:

•    Последний коммит выигрывает  - оба обновления являются успешными, а второе изменение перезаписывает изменения первого. Сообщение об ошибке не показывается.

•    Первый коммит выигрывает – первая модификация записывается, а пользователь, предоставивший второе изменение, получает сообщение об ошибке. Пользователь должен перезапустить бизнес-процесс, получая обновленные комментарии. Этот вариант часто называют оптимистической блокировкой.

•    Слияние конфликтующих обновлений – первая модификация записывается, а вторая может применяться пользователем по выбору.

Первый вариант, где последний выигрывает, проблематичен; второй пользователь перезаписывает изменения первого пользователя, не видя изменений, внесенных первым пользователем, даже зная, что они существуют.  В нашем примере, это вероятно, не имело бы значения, но это было бы неприемлемо для некоторых других видов данных. Второй и третий варианты, как правило приемлемы для большинства видов данных. С нашей точки зрения, третий вариант, это просто изменений второго – вместо того, чтобы показывать сообщение об ошибке, мы показываем сообщение, а затем позволяем пользователю вручную объединить изменения. Не существует единственного наилучшего решения. Вы должны исследовать собственные бизнес-требования, чтобы выбрать между этими тремя вариантами.

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

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

5.2.1 Использование управляемого версионирования

Управляемой версионирование основывается либо на номере версии, который увеличивается или на метке, которая обновляется в настоящем времени, при любом изменении объекта. Для управляемого версионирования в Hibernate, мы должны добавить новое свойство для нашего класса Comment и отобразить его в качестве номера версии, используя тег . Во-первых, давайте посмотрим на изменения в классе Comment:

public class Comment {
  ...
  private int version;
  ...
  void setVersion(int version) {
    this.version = version;
  }
  int getVersion() {
    return version;
  }
}

Вы можете также использовать модификаторы public для сеттера и геттера. Свойство должно прийти сразу после отображения идентификатора в файле отображения для класса Comment:

<class name="Comment" table="COMMENTS">
<id ...
<version name="version" column="VERSION"/>
...
</class>

Номер версии – это просто счетчик, он не имеет какой-либо полезного семантического значения. Некоторые люди предпочитают использовать временные метки(timestamp), вместо счетчика:

public class Comment {
  ...
  private Date lastUpdatedDatetime;
  ...
  void setLastUpdatedDatetime(Date lastUpdatedDatetime) {
    this.lastUpdatedDatetime = lastUpdatedDatetime;
  }
  public Date getLastUpdatedDatetime() {
    return lastUpdatedDatetime;
  } 

}

<class name="Comment" table="COMMENTS">
<id ...../>
<timestamp name="lastUpdatedDatetime" column="LAST_UPDATED"/>
...
</class>

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

    Вам не нужно устанавливать значение версии или временной метки самому; Hibernate будет инициализировать значение, когда вы впервые сохраните Comment и увеличит и сбросит его при каждом изменении объекта.

FAQ    Если версия родительского объекта изменится, то изменится ли наследник? Например, если одна ставка в коллекции ставок Item изменится, то изменится ли номер версии для Item или нет? Ответ на этот и подобные вопросы прост: Hibernate будет увеличивать номер, когда объект «загрязнен»(dirty). Это включает в себя все «грязные» свойства, будь то одиночные значения или коллекции. Подумайте о взаимоотношениях Item и Bid: если изменяется Bid, то версия связанного Item не увеличивается. Если мы добавим или удалим  Bid из коллекции ставок, то версия Item будет обновлена (конечно, мы хотели бы сделать Bid неизменяемым классом, поскольку не имеет смысла изменять ставки).

Всякий раз, когда Hibernate обновляет комментарий, он использует колонку с версией в SQL WHERE условии:

update COMMENTS set COMMENT_TEXT='New comment text', VERSION=3
where COMMENT_ID=123 and VERSION=2

Если другая транзакций приложения будет обновлять этот же элемент, то поскольку он был считан в текущей транзакции приложения, столбец с версией не будет содержать значение 2, и строка не будет обновлена. Hibernate будет проверять количество строк, возвращаемых JDBC драйвером –которые в данном случае будут обозначать количество обновляемых строк, если их количество будет равно нулю, то будет выброшено исключение StaleObjectStateException.

    Используя это исключение, мы можем показать пользователю второй транзакции приложения сообщение об ошибке («Вы работали с устаревшими данными, поскольку другой пользователь изменил их!»), и пусть первая транзакция выиграет. Кроме того, мы могли бы поймать исключение и показать второму пользователю новый экран, позволяющий пользователю вручную произвести слияние между двумя версиями.

    Как вы можете видеть, Hibernate позволяет с легкостью использовать версии для осуществления оптимистической блокировки. Можете ли вы использовать оптимистические и пессимистические блокировки вместе, или вы можете принять решения только в пользу одной блокировки? А почему она называется оптимистической?

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

    Конечно, обе стратегии имеют свои области применения. Многопользовательские приложения обычно по умолчанию используют оптимистический контроль параллелизма и используют пессимистические блокировки, когда это необходимо. Обратите внимание, что продолжительность пессимистической блокировки в Hibernate является продолжительность одной транзакции БД! Это означает, что вы не можете использовать эксклюзивную блокировку, чтобы заблокировать одновременный доступ дольше, чем на одну транзакцию БД. Мы считаем, что это хорошо, потому что единственным решением была бы чрезвычайно дорогая блокировка в памяти (или так называемая блокировка таблицы в БД) на срок, например, транзакции приложения. Это почти всегда узкое место в производительности; каждый доступ к данным требует дополнительной проверки блокировки с синхронизированным менеджером блокировок. Вы можете, если это сильно необходимо в вашем конкретном приложении, осуществлять простую длительную пессимистичную блокировку, используя Hibernate для управления блокированием таблицы. Шаблоны для этого могут быть найдены на сайте Hibernate, но мы определенно не рекомендуем такой подход. Необходимо внимательно изучить последствия этого исключительного случая.

    Давайте вернемся к транзакциям приложения. Теперь вы знаете основы управляемого версионирования и оптимистической блокировки. В предыдущих главах (а ранее в этой главе), мы говорили о Hibernate-сессии, как не о том, что является транзакцией. В самом деле, сессия имеет большую гибкость, и её можно использовать по-разному с БД и транзакциями приложения. Это означает, что степень детализации(гранулированности) является гибкой; это может быть любая единица работы, по вашему желанию.

5.2.2 Детализации сессии

Чтобы понять, как можно использовать Hibernate-сессию, давайте рассмотрим отношения между транзакциями. Ранее, мы обсуждали две взаимосвязанные концепции:

•    Уровень идентичности (см. раздел 4.1.4)

•    Детализацию БД и транзакций приложения

Hibernate сессия определяет сферу идентичности объекта. Транзакция Hibernate соответствует сфере транзакций БД.

(РИСУНОК 5.2)

Какова взаимосвязь между сессиями и транзакциями приложения? Давайте начнем обсуждение с наиболее распространенным использованием сессии.

Обычно, мы открываем новую сессию для каждого запроса клиента (например, запроса веб-браузера) и начинаем новую транзакцию. После выполнения бизнес-логики, мы фиксируем изменений транзакции БД и закрываем сессию перед отправкой ответа клиенту (см. рис. 5.2).

Сессии (S1) и транзакции БД (T1) имеют одну и ту же степень детализации. Если вы работаете с концепцией транзакций приложения, то это простой подход – все что вам нужно в вашем приложении. Нам нравится называть такой подход сессия-на-запрос.

Если вам необходима длительная транзакция приложения, то вам могут помочь несвязанные объекты (и Hibernate поддерживает оптимистическую блокировку, обсуждаемую в предыдущем разделе), осуществите его, используя тот же подход (см. рис. 5.3).

Предположим, что ваша транзакция приложения охватывает два клиентских запроса/ответа, например два HTTP-запроса в веб-приложении. Вы можете загрузить интересующие объекты в первой сессии, а затем связать их к новой сессии после того, как они были изменены пользователем.  Hibernate автоматически проверит версию. Время между (S1, T1) и (S2, T2) может быть «длинным», настолько длинным, насколько это нужно пользователю, чтобы сделать его изменения. Этот подход известен также, как сессия-на-запрос-с-несвязанными-объектами.

    Кроме того, вы можете предпочесть использовать одну сессию, которая охватывает несколько запросов вашей транзакции приложения. В этом случае, вам не нужно беспокоиться о присоединении несвязанных объектов, так как объекты остаются хранимыми в рамках одной длительной сессии (см. рис. 5.4). Конечно, Hibernate по-прежнему несет ответственность за выполнение оптимистической блокировки.

    Сессия сериализуемая и может быть безопасно сохранена, например, в сервлете HttpSession. Конечно, базовое JDBC соединение должно быть закрыто и новое соединение должно быть получено на следующий запрос. Вы используете методы disconnect() и reconnect() интерфейса сессии для того, чтобы освободить соединение и затем получать новое соединение. Такое подход известен, как сессия-на-транзакцию-приложения или длинная сессия.

    Как правило, ваш первый выбор должен сохранять Hibernate сессию открытой не более, чем на одну транзакцию БД (сессия-на-запрос). После завершения первоначальной транзакции БД, чем дольше сессия остается открытой, тем больше шансов, что она удерживает устаревшием данные в КЭШе хранимых объектов (кэш первого уровня является обязательным в сессии). Конечно, вы никогда не должны повторно использовать одну сессию дольше, чем это требуется для завершения одной транзакции приложения.

    Вопрос о реализации транзакций приложения и объем сессии важен при построении приложения. Мы обсудим реализацию стратегии, с примерами в главе 8 «Реализация транзакций приложения».

    В заключении, существует важный вопрос, которым вы можете быть обеспокоены. Если вы работаете с предоставленной схемой БД, то вы, вероятно, не можете добавить колонки версию или временных отметках для оптимистической блокировки в Hibernate.

5.2.3 Другие способы реализации оптимистической блокировки

Если у вас не колонок с версией или временной отметки, то Hibernate может выполнять оптимистическую блокировку, но только для объектов, которые извлечены и изменены в той же сессии. Если вам необходима оптимистическая блокировка для несвязанных объектов, то вы должны использовать номер версии или временные метки.

    Это альтернативная реализация оптимистической блокировки проверяет  текущее состояние БД, на неизменность значений хранимые свойств, в то время, как объект был извлечен (или во время последней очистки сессии). Вы можете включить эту функцию, установив optimistic-lock атрибут в файле отображения класса:

<class name="Comment" table="COMMENT" optimistic-lock="all">
<id ...../>
...
</class>

Сейчас, Hibernate будет включать все свойства в WHERE условие:

update COMMENTS set COMMENT_TEXT='New text'
where COMMENT_ID=123
and COMMENT_TEXT='Old Text'
and RATING=5
and ITEM_ID=3
and FROM_USER_ID=45

Кроме того, Hibernate будет включать только изменяемые свойства (только COMMENT_TEXT в данном примере) если вы выставите optimistic-lock=”dirty” (заметим, что этот параметр также требует, чтобы вы установили файл отображения класса в dynamic-update=”true”).

    Мы не рекомендуем этот подход; он медленный, более сложный и менее надежный, чем номер версии и не работает, если ваша транзакция приложения охватывает несколько сессий (как в случае, если вы используете несвязанные объекты).

    Мы теперь снова переключимся и рассмотрим новый аспект Hibernate. Мы уже упоминали о тесной взаимосвязи между транзакциями и кэшированием во введении этой главы. Основы транзакций и блокировки, а также детализация сессий, имеют важнейшее значение, если учесть кэширование данных на уровне приложения.

Кэширование в Hibernate (Ч4) 
Hibernate кэширование на практике и заключение (Ч5)

Очистка сессии, уровни изоляции транзакций, выбор и установка уровня изоляции транзакций в Hibernate (Ч2)

это перевод книги Hibernate In Action Главы 5
Hibernate транзакции, параллельность и кэширование. Основы транзакций. (Ч1)

5.1.3 Очистка Session
Hibernate интерфейс Session реализует прозрачную запись. Изменения в модели предметной области, сделанные в области действия Session не распространяются немедленно на БД. Это позволяет Hibernate объединять множество изменений в минимальном количестве запросов к БД, помогая свести к минимуму воздействие задержек сети.

Например, если одно свойство объекта изменилось дважды в одной Transaction, Hibernate нужно выполнить только один SQL UPDATE. Другим примером полезности прозрачной записи, является то, что Hibernate может воспользоваться преимуществами пакетного(batch) выполнения запросов JDBC, когда выполняет несколько UPDATE, INSERT или DELETE выражений.
Очистка Hibernate сессии происходит только в следующих случаях:
•    когда Transaction фиксируется(коммит);
•    иногда перед выполнением запроса;
•    когда приложение вызывает Session.flush() явно;

Очистка состояния сессии в БД в конце транзакции БД необходимо для того, чтобы сделать изменения долговечными. Hibernate не очищает  сессию перед каждым запросом. Однако, если есть изменения хранимые в памяти, которые могут повлиять на результат запроса, то Hibernate, по умолчанию, синхронизирует их в первую очередь.

    Вы можете контролировать это поведение явно, устанавливая Hibernate FlushMode через вызов Session.setFlushMode(). Режимами очистки сессии являются:
•    FlushMode.AUTO – по умолчанию. Устанавливает поведение, описанное только что.
•    FlushMode.COMMIT – указывает, что сессия не будет очищена перед выполнением запроса (она будет очищена только в конце транзакции БД). Имейте в виду, что этот параметр может затронуть устаревшие данные: изменения, внесенные в объекты только в памяти, могут вступать в противоречие с результатами запроса.
•    FlushMode.NEVER – позволяет вам самим указать, что только явные вызовы flush()  приведут к синхронизации состояния сессии с БД.
 
Мы не рекомендуем вам изменять эту настройку по умолчанию. Это позволяет организовать оптимизацию производительности в редких случаях. Аналогичным образом, большинству приложений редко нужно указывать flush() явно. Эта функция полезна, когда вы работаете с триггерами, смешивая Hibernate с прямым JDBC, или работает с ошибками JDBC драйверов. Вы должны быть осведомлены о такой возможности, но необязательно использовать её.
Теперь вы понимаете, что основой использования транзакций с Hibernate является интерфейс Transaction, давайте обратим наше внимание на одновременный доступ к данным.

Может показаться, как будто вы не должны заботиться об изоляции транзакции – термин подразумевает, что что-то является и не является изолированным. Это вводит в заблуждение. Полная изоляция одновременных операций является исключительно дорогостоящей операцией, с точки зрения масштабируемости приложений, поэтому БД предоставляет несколько степеней изоляции. Для большинства приложений, частичная изоляция транзакций является приемлемым вариантом. Важно понимать, что степень изоляции следует выбирать для приложения, которое использует Hibernate, а также понимать, как Hibernate интегрируется с возможностями транзакций БД.
 
5.1.4 Понимание уровней изоляции
БД (и другие транзакционные системы) пытаются обеспечить изоляцию транзакций, а это означает, что, с точки зрения каждой одновременной транзакции, никакие другие транзакции не выполняются.
    Традиционно, это реализуется с использованием блокировок. Транзакция может установить блокировки на конкретный элемент данных, временно предотвращая доступ к этому элементу, другим транзакциям. Некоторые современные БД, такие как Oracle и PostgreSQL реализуют изоляцию транзакций, используя многоверсионный контрольно-измерительный параллелизм, который обычно считается более масштабируемым решением. Мы обсудим изоляцию, предполагая модель блокировок (большинство из наших наблюдений также применимы к многоверсионному параллелизму).
    Эта дискуссия о транзакциях БД и об уровне изоляции, предоставляемому БД.  Hibernate не добавляет дополнительную семантику; он использует  все, что доступно с данной БД. Если вы следили за многолетним опытом, которые поставщики БД имели, реализуя контроль параллельности, то вы будете четко видеть преимущества этого подхода. Ваша задача, как разработчика Hibernate приложений, состоит в том, чтобы понять возможности вашей СУБД и как можно изменить поведение  изоляцию БД, в случае необходимости, конкретно в вашем сценарии (и по вашим требованиям целостности данных).

Вопросы изоляции
Во-первых, давайте взглянем на некоторые явления, которые нарушают полную изоляцию транзакций. Стандарт ANSI SQL определяет стандартные уровни изоляции транзакций, с точки зрения того, какие из этих явлений являются допустимыми:
•    Потерянное обновление – две транзакции обновляют строку, а затем вторая прерывает транзакцию, в результате чего оба изменения будут потеряны. Это происходит в системах, которые не реализуют какую-либо блокировку. Одновременные транзакции не изолированы.
•    Грязное чтение - одна транзакция читает изменения, сделанные в другой транзакции, которая ещё не до конца совершена. Это очень опасно, потому что эти изменения не зафиксированы.
•    Неповторяемое чтение – транзакция читает строку дважды и считывает различные состояния каждый раз. Например, другая транзакция может быть записана в строку и зафиксирована между двумя считываниями.
•    Вторая проблема обновлений – частный случай неповторяемого чтения. Представьте себе, что есть две параллельные транзакции, обе читают строки, одна записывает туда и фиксируется, и далее вторая пишет туда же и фиксируется. Изменения, сделанные первой транзакцией, будут потеряны.
•    Фантомное чтение – транзакция выполняет запрос дважды, и второй результирующий набор включает в себя строки, которые были не видны в первом результирующем наборе (это не обязательно должен быть точно такой же запрос). Такая ситуация вызвана другой транзакцией, которая вставляла новые строки между выполнением этих двух запросов.

Теперь, когда вы понимаете все плохое, что может произойти, мы можем определить различные уровни изоляции транзакций и увидеть, какие проблемы они предотвращают.
Уровни изоляции
Стандартные уровни изоляции определяются стандартом ANSI SQL, но без привязки к SQL БД. JTA определяет те же уровни изоляции, и вы будете использовать эти уровни, чтобы позднее заявить желаемые уровень изоляции транзакции:
•    Неподтверждённое чтение – разрешает грязные чтения, но без потери обновлений. Одна транзакция может не писать в строку, если другая незафиксированная транзакция уже записывает туда. Однако, любая транзакция может читать любые строки. Этот уровень изоляции может быть реализован с использованием эксклюзивной блокировки записи.
•    Подтверждённое чтение  - разрешает неповторяемые чтения, но не грязные чтения. Это может быть достигнуто с помощью мгновенных общих блокировок чтения и эксклюзивной блокировки записи. Однако, незафиксированные пишущие транзакции блокируют  все другие транзакции на доступ к строке.
•    Повторяемое чтение – не допускает ни неповторяемого чтения, ни грязного чтения. Фантомное чтение может произойти. Это может быть достигнуто с использованием общих блокировок на чтение и эксклюзивной блокировки на запись. Блок чтения пишущих транзакций (но не другие операции чтения) и блок  пишущих транзакций блокируют все другие транзакции.
•    Упорядоченный (сериализуемый) – обеспечивает строгую изоляцию транзакций. Он эмулирует последовательное выполнение операций, как если бы операция была выполнена одна за другой последовательно, а не параллельно. Упорядоченность не может быть реализована с использованием только блокировки на уровне строк; это должен быть другой механизм, который предотвращает становление видимой, только что вставленной строки, из транзакции, которая уже выполняет запрос, возвращающий строку.
Приятно знать, как определены все эти технические термины, но как это поможет вам выбрать уровень изоляции, необходимый для вашего приложения?

5.1.5 Выбор уровня изоляции
Разработчики (включая нас) зачастую не уверены в уровне изоляции транзакций для использования в работающих приложениях. Слишком большая степень изоляции повредит производительность приложений с большим количеством одновременных операций. Недостаточная изоляция может привести к тонким ошибкам в нашем приложении, которые не могут быть воспроизведены, и мы никогда не узнаем об их наличии, пока система не поработает под большой нагрузкой.
    Обратите внимание на то, что мы называем кэшированием и оптимистической блокировкой (с помощью версионирования), эти две концепции объясняются позже в этой главе. Вы можете пропустить этот раздел и вернуться, когда придет время принимать решение по уровню изоляции в вашем приложении. Выбор правильного уровня изоляции, в конце концов, в значительной степени зависит от конкретного сценария. Это обсуждение содержит рекомендации; это не является прописными истинами.
    Hibernate старается быть как можно более прозрачным в отношении семантики транзакций БД. Тем не менее, кэширование и оптимистические блокировки влияют на эти семантики. Итак, что же представляет собой разумный уровень изоляции БД в Hibernate приложении?
    Во-первых, устраните уровень чтения неподтвержденного. Крайне опасно использовать изменения, незафиксированные одной транзакцией, в других.  Откат или сбой одной транзакции повлияет на другие параллельные транзакции. Откат первой транзакции может сбить другие транзакции или, возможно, даже оставить БД в противоречивом состоянии. Вполне возможно, что изменения, внесенные транзакцией, которая заканчивается во время отката, могут быть зафиксированы в любом случае, поскольку они могут быть считаны и затем распространятся  на другую транзакцию, которая была успешна!
    Во-вторых, большинству приложений не нужна упорядоченная (сериализованная)  изоляция (фантомное чтение обычно не проблема), и  этот уровень изоляции, как правило, плохо масштабируется. Немногие из существующих приложений используют упорядоченную изоляцию в работающем приложении; а скорее они используют пессимистическую блокировку (см. раздел 5.1.7, «Использование пессимистических блокировок»),  которая эффективно справляется с упорядоченным выполнением   операций в определенных ситуациях.
    Это оставляет вам выбор между чтением подтвержденного  и повторяемого чтения. Этот уровень изоляции исключает вероятности того, что одна транзакция может перезаписать изменения, сделанные другой параллельной транзакцией (вторая проблема  потери обновлений), если доступ к данным осуществляется в одной атомарной транзакции БД. Это важный вопрос, но использование повторяемого чтения не является единственным путем к его решению.
    Предположим, что вы используете версионирование данных, то, что Hibernate может сделать для вас автоматически. Сочетание (обязательного) сессионного Hibernate-кэша первого уровня и версионирования уже дают вам большинство функций для изоляции повторяемого чтения. В частности, версионирование предотвращает вторую проблему потери обновлений, и сессионный кэш первого уровня гарантирует, что состояние хранимых сущностей, загружаемых одной транзакцией, изолированы от изменений, делаемых в других транзакциях. Таким образом, изоляция чтения зафиксированного для всех транзакций БД было бы приемлемо, если вы используете версионирование данных.
    Повторяемое чтение обеспечивает немного большую воспроизводимость для результатов запроса (только на время транзакции БД), но поскольку фантомное считывание все ещё возможно, существует не так много смысла в этом (запрашивать одну таблицу дважды в одной транзакции  также не характерно для веб-приложений).
    Вы также можете рассмотреть (по желанию) Hibernate кэш второго уровня. Он может обеспечить такую же изоляцию транзакций, как и транзакция БД, но он может даже ослабить изоляцию. Если вы интенсивно используете стратегию параллельного кэширования для КЭШа второго уровня, который сохраняет семантику повторяемого чтения (например, для стратегии чтения-записи и особенно для стратегии нестрогого чтения-записи, обе они обсуждаются ниже в этой главе), выбор уровня изоляции по умолчанию прост: вы не можете достичь повторяемого чтения в любом случае, так что нет смысла в замедлении БД. С другой стороны, вы можете не использовать кэш второго уровня для критических классов, или вы можете полностью использовать транзакционный кэш, который обеспечивает изоляцию повторяемого чтения. Должны ли вы использовать повторяемое чтение в этом случае? Вы можете, если хотите, но это, наверное, не стоит накладных расходов.
    Установка уровня изоляции транзакций позволяет выбрать хорошую стратегию блокировки по умолчанию для всех ваших транзакций БД. Как установить уровень изоляции?

5.1.6 Установка уровня изоляции
Каждое JDBC соединение к БД использует уровень изоляции, установленный самой БД, как правило, это чтение подтвержденного или повторяемое чтение. Это значение по умолчанию может быть изменено в конфигурации БД. Вы также можете установить уровень изоляции транзакций для JDBC соединений, с помощью опции конфигурации Hibernate:

    hibernate.connection.isolation = 4

Hibernate затем установит этот уровень изоляции на каждое соединении JDBC, полученное из пула соединений, до начала транзакции. Разумные значения для этой опции выглядят следующим образом (вы также можете найти их, как константы в java.sql.Connection):
•    1 – изоляция уровня чтения неподтвержденного;
•    2 – изоляция уровня чтения подтвержденного;
•    4 – изоляция уровня повторяемого чтения;
•    8 – упорядоченная изоляция.

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

Пессимистическая и оптимистическая блокировки, транзакции приложения, версионирование, детализация сессии (Ч3) 
Кэширование в Hibernate (Ч4) 
Hibernate кэширование на практике и заключение (Ч5)