Представляю вашему вниманию перевод второй главы официальной документации Hibernate.

Перевод статьи актуален для версии Hibernate 4.2.19.Final

Содержание

 2.1. Определение транзакции
 2.2. Физические транзакции
   2.2.1. Физические транзакции — JDBC
   2.2.2. Физические транзакции — JTA
   2.2.3. Физические транзакции — CMT
   2.2.4. Физические транзакции — Прочее
   2.2.5. Физические транзакции — Устаревшее
 2.3. Применение транзакций Hibernate
 2.4. Паттерны и анти-паттерны транзакций
   2.4.1. Анти-паттерн сессия-на-операцию
   2.4.2. Паттерн сессия-на-запрос
   2.4.3. Диалоги (Conversations)
 2.5. Идентичность объекта
 2.6. Общие вопросы

Привет, Хабр! Эта публикация — попытка развеять некоторые популярные мифы и легенды о MySQL. Я не ошибся с хабом, так как поводом для написания послужила публикация varanio Возможности PostgreSQL, которых нет в MySQL, и наоборот отсюда же. Сама публикация в части критики MySQL хоть и неидеальна, но вполне корректна, а вот комментарии к ней наводят на грустные размышления.

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

Представляю вашему вниманию перевод шестой главы официальной документации Hibernate.

Перевод статьи актуален для версии Hibernate 4.2.19.Final

Предыдущая глава — Документация разработчика Hibernate – Глава V. Блокировки

Что собой представляют кэш первого и второго уровня в Hibernate, показано на следующий диаграмме (прим. автора).

6.1. Кэш запросов

Если у вас есть запросы, выполняющиеся снова и снова, с одними и теми же параметрами, кэширование запросов предоставит выигрыш в производительности.

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

Многие боятся переходить с «мускуля» на «посгрес» из-за того, что лишь смутно понимают, что это даст. Некоторых останавливает мысль, что наверно Postgres — это слишком сложная база и требует обучения. А также, что возможно чего-то придется лишиться в связи с переходом. Попробую немного прояснить ситуацию.

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

Предположим, у вас есть prod и test базы данных. В какой-то момент разработчик внес изменения в тестовую базу, но забыл внести эти изменения в боевую базу. Если это часто используемая таблица, то ситуация очень быстро становится очевидной, так как в логах появятся ошибки в SQL-запросах и вам начинает звонить начальник с упреками «какого @#$%».

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

Еще вариант — вы провели обновление ПО и у вас все перестало работать. Куча непонятных ошибок на пустом месте, приложение лежит, пользователи не довольны.

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

Изначально эта статья задумывалась только для разработчиков и администраторов СУБД Firebird, но после общения с администраторами других БД выяснилось, что большинство ошибок общие, и на очень похожие грабли наступают буквально все. Если Вы можете что-то добавить к этому списку (пусть даже специфическое для конкретной СУБД), пишите в личную почту или в комментариях.
In English: 12 Common Mistakes while Backing Up Databases

Наша компания занимается инструментами восстановления, резервного копирования, оптимизации и поддержкой СУБД (в основном Firebird, но есть и MSSQL, PostgreSQL, InterBase и др.) и, как результат многочисленных аудитов и ремонтов, накопила коллекцию ошибок, связанных с резервным копированием. Все пункты ниже изложены по мотивам реальных случаев с повреждением баз, потерей и повреждением бэкапов, дисков, сбоями серверов, и прочих «радостей» администраторов БД.

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

Итак, приступим.

Введение

Apache и Nginx — 2 самых широко распространенных веб-сервера с открытым исходным кодом в мире. Вместе они обслуживают более 50% трафика во всем интернете. Оба решения способны работать с разнообразными рабочими нагрузками и взаимодействовать с другими приложениями для реализации полного веб-стека.

Несмотря на то, что у Apache и Nginx много схожих качеств, их нельзя рассматривать как полностью взаимозаменямые решения. Каждый из них имеет собственные преимущества и важно понимать какой веб-сервер выбрать в какой ситуации. В этой статье описано то, как каждый из этих веб-серверов ведет себя при различных условиях.

Вокруг постоянно говорят про Docker. Я знаю что вы отвечаете: «Это что-то про контейнеры, виртуализацию, облака», «У нас все и так работает», «Это все баловство», «Он не запустится на нашем старом ядре линукса», «Точно так же можно подготовить образ для облака и запустить его», «Можно просто настроить LXC, chroot или AppArmor». Вы знаете, что он вам не нужен. Очередная модная штука. В конце концов, просто лень разбираться. Но любопытно! Тогда, читайте. Это серия из шести заметок.

Если вы не слышали о контейнерах в Линуксе, вот список страниц, которые надо прочитать, чтобы понимать о чем речь:

• en.wikipedia.org/wiki/LXC
• en.wikipedia.org/wiki/UnionFS
• habrahabr.ru/post/253877
• www.docker.com/whatisdocker

Поставьте Docker, он небольшой. Для Windows и Mac можно просто поставить Toolbox: www.docker.com/toolbox. Создавать виртуальную машину и настраивать лучше из командной строки, а не через графическую обертку. Прочитайте несколько уроков из мануала. Здесь я пишу о том, чего в документации нет.

Docker — это не виртуализация.

Вот какой у меня линукс:

Welcome to Ubuntu 15.04 (GNU/Linux 3.19.0-15-generic x86_64)

Last login: Tue Aug 18 00:43:50 2015 from 192.168.48.1
gri@ubuntu:~$ uname -a
Linux ubuntu 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/                                       Linux
gri@ubuntu:~$ free -h
             total       used       free     shared    buffers     cached
Mem:          976M       866M       109M        11M       110M       514M
-/+ buffers/cache:       241M       735M
Swap:         1.0G       1.0M       1.0G

Запускаю CentOS:

gri@ubuntu:~$ docker run -ti centos
[root@301fc721eeb9 /]# uname -a
Linux 301fc721eeb9 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@301fc721eeb9 /]# cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)
[root@301fc721eeb9 /]# free -h
              total        used        free      shared  buff/cache   available
Mem:           976M         85M        100M         12M        790M        677M
Swap:          1.0G        1.0M        1.0G

Docker — это не chroot, их функционал частично совпадает. Это не система безопасности вроде AppArmor. Docker использует те же контейнеры, что и LXC, но интересен он не контейнерами. Docker — это ничего из того, что я думал о нем до того, как прочитал документацию.

То же ядро, память, файловая система, а дистрибутивы, библиотеки и пользователи — разные.

Docker — это инструмент объекто-ориентированного проектирования

Регулярно возникает вопрос, является ли конфигурация nginx частью веб-приложения. Системные администраторы спорят с разработчиками. Но недавно в мире появились devops и захотели вместо последовательно-процедурного вызова команд из bash думать привычным OOP. Docker дает инкапсуляцию, наследование и полиморфизм компонентам системы, таким как база данных и данные. Это значит, что можно провести декомпозицию всей информационной системы, выделить приложение, web-сервер, базу данных, системные библиотеки, рабочие данные в независимые компоненты, внедрять зависимости из конфигов, и заставить все это работать одной группой, одинаково на разных компьютерах.

Такой подход можно использовать, чтобы снизить потери рабочего времени дорогих front-end разработчиков на настройку базы данных и Nginx. Чтобы уйти от vendor lock-in. Не обломаться когда openssl на сервере не поддерживает cipher, используемый в API госучреждения. Чтобы приложение работало независимо от версии PHP или Python на сервере заказчика. Создавать open source не только в виде кода, но и настройкой пакетов из нескольких приложений, написанных на разных языках, работающих на разных слоях OSI.

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

Что это и зачем оно надо: Как известно, главное преимущество Java мира в том в нем существует огромное количество open-source проектов на на все случаи жизни, однако найти нужный на github'e не так просто, так как описание проекта часто мало информативно, зачастую сложно даже понять этот проект для Android'a или нет. В этой статье я автоматически и полуавтоматически собрал Java проекты, убрал старые и проекты только для Android'a, выбрал 350 набравших больше всего звезд, разделил по категориям и перевел описания.

Если вы хотите убедиться что базы данных пишут не только на C, найти проекты для работы с большими данными или нейронными сетями, пишите свой язык программирования для JVM и хотите посмотреть как это уже сделано или же просто хотите узнать какие новые возможности можно найти в Java мире open-source то это статья вам, думаю, может пригодится.


Другие статьи серии: часть 1. JPA и Hibernate в вопросах и ответах

Update: Внимание, актуальная версия со много большим количеством ссылок, находиться теперь в моем github'e проекте useful-java-links, по этой ссылке.

Добрый день.
В рамках набора на курс «Multicore programming in Java» я делаю серию переводов классических статей по многопоточности в Java. Всякое изучение многопоточности должно начинаться с введения в модель памяти Java (New JMM), основным источником от авторов модели является «The Java Memory Model» home page, где для старта предлагается ознакомится с JSR 133 (Java Memory Model) FAQ. Вот с перевода этой статьи я и решил начать серию.
Я позволил себе несколько вставок «от себя», которые, по моему мнению, проясняют ситуацию.
Я являюсь специалистом по Java и многопоточности, а не филологом или переводчиком, посему допускаю определенные вольности или переформулировки при переводе. В случае, если Вы предложите лучший вариант — с удовольствием сделаю правку.
Этот статья также подходит в качестве учебного материала к лекции «Лекция #5.2: JMM (volatile, final, synchronized)».

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

Ну и да, приходите учиться ко мне!

---

JSR 133 (Java Memory Model) FAQ

Jeremy Manson и Brian Goetz, февраль 2004

Содержание:
Что такое модель памяти, в конце концов?
Другие языки, такие как C++, имеют модель памяти?
Что такое JSR 133?
Что подразумевается под «переупорядочением» (reordering)?
Что было не так со старой моделью памяти?
Что вы подразумеваете под «некорректно синхронизированы»?
Что делает синхронизация?
Как может случиться, что финальная поля меняют значения?
How do final fields work under the new JMM?
Что делает volatile?
Решила ли новая модель памяти «double-checked locking» проблему?
Что если я пишу виртуальную машину?
Почему я должен беспокоиться?

В данной статье рассмотрена интеграция разовых платежей, а также оплаты по подписке с помощью Paypal в веб-приложение. Примеры реализованы на PHP, но, в принципе, без особых проблем то же самое можно сделать с помощью других технологий. Данный метод выбран как компромисс между простотой и гибкостью. Это попытка написать руководство, которое поможет быстро разобраться в теме и интегрировать оплату через Paypal в свой проект.

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

На Хабре и в нашем блоге о корпоративном IaaS мы много пишем об облачных технологиях, и рассматриваем интересные инфраструктурные проекты различных компаний. Сегодня поговорим о повышении производительности git-сервера и взглянем на историю и опыт проекта Clever Cloud.

Обычно дизайн приложения рисуется в векторном редакторе (например, Sketch), но типичным форматом картинок в приложении под Android является растровый (как правило, PNG). При разработке приложения необходимо для каждого векторного изображения заниматься утомительной работой по изготовлению набора растровых картинок для разных плотностей экранов. Количество таких комплектов может доходить до шести по числу возможных плотностей: ldpi, mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi (плотность xxxhdpi необходима только для иконки приложения). При верстке иногда приходится задать в разметке явные размеры для изображения, что может потребовать перемасштабирования растровой картинки, а это, в свою очередь, наверняка приведет к появлению артефактов. К тому же наличие нескольких комплектов картинок отрицательно сказывается на размере выходного apk.

В последние несколько лет MongoDB приобрела огромную популярность среди разработчиков. То и дело в интернете появляются всякие статьи, как очередной молодой популярный проект выкинул на свалку истории привычные РСУБД, взял в качестве основной базы данных MongoDB, выстроил инфраструктуру вокруг неё, и как все после этого стало прекрасно. Даже появляются новые фреймворки и библиотеки, которые строят свою архитектуру целиком на Mongo (Meteor.js например).

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

Все что описано ниже можно воспроизвести с использованием библиотеки PyMongo для работы с MongoDB из языка программирования Python. Однако скорее всего с аналогичными ситуациями вы можете столкнуться и при использовании других библиотек для других языков программирования.

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

CSS-препроцессоры в своё время значительно облегчали работу по написанию CSS кода. Однако в некотором роде все они были несовершенны и имели значительные изъяны в работе. А потому на смену препроцессорам пришёл постпрепроцессор PostCSS.

Это довольно таки мощный инструмент, облегчающий работу с CSS. Постпрепроцессор уже сегодня используется в таких крупных компаниях как Twitter и Google. Кроме того, по сообщениям разработчиков Bootstap, пятая версия CSS-фреймворка вероятнее всего также будет написана на PostCSS.

Если вы владелец интернет-магазина и хотите, чтобы покупатель мог оплатить товары удобным ему способом, у вас есть два пути: подключать и настраивать оплату для каждой платежной системы отдельно — мучиться с интеграцией, подписанием договоров… либо сделать все быстро и без лишней волокиты — воспользоваться услугами компании, которая является платежным агрегатором. При выборе последнего варианта вам понадобится подписать всего один договор, а ваш покупатель сможет выбрать удобный ему способ оплаты из десятков доступных. Это и оффлайн способы, и электронные кошельки и, конечно же, оплата банковской картой. Платежных агрегаторов множество.

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

Чем же платежные агрегаторы отличаются друг от друга, и на что стоит обратить внимание?

Каждую компанию было решено рассмотреть по десяти параметрам. Ниже приведено детальное описание параметра и почему на это стоит обратить внимание.

На днях Алексей Владышев зашёл в гости к Константину Буркалёву. Поговорили на разные темы и в том числе о Zabbix, куда без него. Получился новый выпуск подкаста SDCast.

Мы узнаем историю создания проекта, как правильно произносить Zabbix и чем отличается Open Core от Free Software. И не только!