Interceptors for Stateless Session Beans

Что за звери такие?

Суть в том, что перед вызовом бизнес-метода будет вызываться метод (или методы) определенных классов.
Все весьма и весьма просто.

1. Мы аннотируем бизнес-метод или бин вот так:

@Interceptors({LogDebugInterceptor.class, NotNullInterceptor.class})

2. В самом перехватчике должен быть метод (методы) а ля

@AroundInvoke
public Object methodName(InvocationContext inv) throws Exception

Они должны быть аннотированы и иметь указанную сигнатуру.

3. Очень интересен интерфейс

public interface InvocationContext {
public Object getTarget();
public Method getMethod();
public Object[] getParameters();
public void setParameters(Object[] params);
public java.util.Map getContextData();
public Object proceed() throws Exception;
}

с помощью него можно получить объект и метод, которые послужил причиной вызова перехватчика. А так же все параметры, переданные в бизнес-метод. Более того, параметры можно подменить с помощью метода setParameters.

4. Для успешного завершения необходимо венуть объект, возвращаемый функцией proceed()

return inv.proceed();

тогда управление будет передано следующему перехватчику, либо бизнес-методу.

Суть схожа с механизмом фильтров в сервлетах. Для чего можно использовать перехватчики? для обработки входных параметров, их проверки, проверки каких-либо ограничений. Например бизнес-метод depositMoney(Customer customer) можно перехватывать для проверки прав клиента на перевод денег.

Modeling principles

In the past three slides we talked a lot about the model that created during software development workflows.
Lets step back a minute and ask an important question. Why do we want to create any these models?
If the ultimate goal is to create software, why should I waste time creating models?
..... then he wrote: we build models we can better understand the system we are developing.

Then building a house you could just buy some lumber and start nailing board together and hope that all that walls fit together.
And then you have room ... a kitchen (м.б. украсить или выбрать кухню).
Such [анхак] approach to build a house is unlike little fail.
Instead you hiring an architect and designer [хелс].
The architect create some model of the [хелс] in his head, but he must share his vision with you, the client.
In the construction [крую], it takes order in a house to construction requeres unique view of the architecture.
You, as an owner need to see artistic renderings of the exterior and landscaping,
the builder need to see three-dimensional views of rooms, doors, stairs and so on.
The electrician needs a wiring view, the plummer needs the view of pipes and so on.

Software development also uses models to represent aspects of the system.
All software developers have a mental model of the system they are building.
You can draw your own diagrams to visualize those mentals models. You can also draw a diagram to capture a design of some existing system.

Communication is very important for success of any software project.
Models help communicate the design and decisions being made about the project.
These decisions must be share with stakeholders, so everyone is on the same page about stages and direction of the project.
In large teams each workflow may be performer by different workers. As the project transitions from one workflow to the next,
it is important that workers document and communicate decisions to the next workflow group.
Models help document those decisions.

Specific UML diagrams show different views of these models.
For example you can use a class diagram to show types ant entities of the system.
And you can use the sequence diagrams to show time order flow of messages between objects to accomplish some functional requirements.

Java memory model in 500 words

Оригинальная статья

Что есть Java Memory Model? JMM объяснаяет почему дважды проверенный лдокинг не работает и как это исправить.

JMM отвечает на простой, казалось бы, вопрос: в какой момент можно будет прочесть значение 3 переменной myVariable после присвоения этого значения.

Правила такие:

• Правило упорядочивания программы. В пределах программы действия происходят в запрограммированном порядке.
• Monitor lock rule. Unlock on monitor происходит до следующего лока.
  
• Volatile variable rule. A write to a volatile happens-before every subsequent read of that volatile.
• Thread start rule. Thread.start happens-before actions in the Thread
• Thread termination rule. Actions in a thread happens-before other threads detect the thread's termination.
• Interruption rule. A thread calling interrupt on another thread happens before the interrupted thread detects the interrupt.
• Finalizer rule. End of object construction happens-before start of object finalization.
• Transitivity. If A happens-before B, and B happens-before C, then A happens-before C.

There you have it, the Java Memory Model in 500 words. This summary has been taken from Brian Goetz's Java Concurrency in Practice, which I can't recommend enough.

1. Используйте статические фабричные методы вместо конструкторо

Вместо конструктора можно использовать статические фабричные методы, как в классах-wrapper'ах, например Integer.valueOf(...)

Отметим, что static factory метод не тоже самое, что шаблон Factory, описываемый метод не имеет прямых аналогов в шаблонах проектирования.

Существует несколько преимуществ такого подхода по сравнению с использованием конструкторов.

Первое преимущество. Можно выбрать "говорящее" имя для static factory метода, что нельзя сделать для конструктора. Выбор имени может улучшить жизнь клиента, его код стоновится более читаемым. К тому же, возможет лишь один конструктор с фиксированным набором параметров, а методов может быть несколько.

Второе преимущество. Принципиальное преимущество заключается в том, что метод не обязан создавать новый экземпляр объекта, он может возвращать ссылку на уже созданный экземпляр, взяв его, например, из кэша. Это позволяет не дублировать экземпляры без необходимости. Такое поведение свойственно методу Boolean.valueOf(boolean). Классы, которые контролируют свои экземпляры подобным образом называют instance-controlled. Есть несколько причин написания instance-controlled классов. Это гарантирует что не существует двух эквивалентных объектов, что позволяет повысить производительность, клиенты могут использовать оператор == вместо equals. Все Enum-ы являются instance-controlled.

Третье преимущество - метод может возвращать экземпляр одного из субклассов, что дает большУю гибкость по сравнению с использование конструктора. Мы можем возврщать экземпляр без объявления класс публичным, т.е. полностью скрывать реализацию, что является ключевым моментом при проектировании компактного API. Интерфейсы не могут иметь статических методов, поэтому принято следующее соглашение. Если интерфейс называется Type, то статические фабричные методы, возвращающие реализации интерфейса, помещаются в класс с именем Types. Подобным образом организован Java Collections Framework. Т.е. все static factory методы сконцентрированы в одном классе и, кроме того, мы скрываем реилизации интерфейса.

Четвертое преимущество. Static factory методы уменьшают количество кода при использованиии generics.

Главный недостаток состоит в том, что нельзя создать субкласс к классу без public или protected конструктора.

Второй недостаток заключается в том, что их, в общем случае, невозможно отличить от других static методов. Обычно прибегают к специальному именованию таких методов:
• valueOf—возвращает объект, содержащий переданный аргумент.
• of—альтернатива valueOf, популярная в Enum-ах.
• getInstance—возвращает экземпляр, который описывается параметрами, но недльзя сказать что имеет тоже самое значение. В случае синглтона возвращает единственный экземпляр.
• newInstance—аналогичен getInstance, но гарантирует создание нового экземпляра.
• getType—аналогичен getInstance, но используется когда factory метод находится в другом классе. Type в данном случае заменяется, например getArrayList.
• newType—аналогичен newInstance.

Вообщем, static factory методы и публичные конструкторы имеют свои области применения.

Effective Java 2nd edition

I will read it in English...

Авто генерация UML диаграм в javadoc

Оригинальная статья

Разобрался как автоматически генерировать и вставлять диаграммы классов и пакетов в javadoc. Заточено под NetBeans. Инога весьма удобно.

Java EE Transactions

Оригинал: http://java.sun.com/javaee/5/docs/tutorial/doc/bncih.html

Глава 33

Транзакции

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

Что такое транзакция?

Для моделирования бизнес-транзакции программе может потребоваться выполнить несколько шагов, например

начало транзакции
  проверка состояния счета
  обновление состояния счета
  запись информации в лог
коммит транзакции

Либо все шаги должны завершиться коректно, либо ни один из них. Иначе целосность данных нарушится. Транзакция может завершиться двумя путями: коммитом, либо откатом (rollback).

Управляемые контейнером транзакции (Container-Managed Transactions)

В enterprise bean с container-managed transaction demarcation границы транзакций выставляет EJB контейнер. Вы можете использовать container-managed transactions как с session так и с message-driven bean. В этом случае разработка упрощается, поскольку Вы не имеете дело с транзакциями явно.

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

Не во всех методах требеются транзакции, поэтому с помощью аттрибутов Вы можете настраивать необходимость использования транзакций.
Бины, не должны использовать методы, которые пересекаются с определением границ транзакций, например методы commit, setAutoCommit, rollback класса java.sql.Connection или commit, rollback класса javax.jms.Session. Если это необходимо, то используйте application-managed transaction demarcation.
Также нельзя использовать интерфейс javax.transaction.UserTransaction.

Аттрибуты транзакции

Аттрибуты транзакции определяют охват транзакции. На рис. 33-1 ставится вопрос: необходимо ли открывать новую транзакцию? Ответ зависит от аттрибутов method-B()

Рис. 33-1

Аттрибуты могут принимать значения:

• Required

• RequiresNew

• Mandatory

• NotSupported

• Supports

• Never

Сводная таблица

Table 33-1 В таблице 33-1 показано поведение контейнера исходя в различных ситуациях при различных значениях аттрибутов.

Таблица 33-1.

Значение аттрибута	Клиентская транзакция	Транзакция метода
Required	None	T2
	T1	T1
RequiresNew	None	T2
	T1	T2
Mandatory	None	error
	T1	T1
NotSupported	None	None
	T1	None
Supports	None	None
	T1	T1
Never	None	None
	T1	Error

Установка значения аттрибута

Аттрибуты определяюся с помощью анотации javax.ejb.TransactionAttribute, им присваивается одно из значений javax.ejb.TransactionAttributeType.

Можно аннотировать как отдельные методы, так и целые классы. Аннотация метода переопределяет аннотацию класса.
TransactionAttributeType содержит соответствующие значения:

• Required: TransactionAttributeType.REQUIRED

• RequiresNew: TransactionAttributeType.REQUIRES_NEW

• Mandatory: TransactionAttributeType.MANDATORY

• NotSupported: TransactionAttributeType.NOT_SUPPORTED

• Supports: TransactionAttributeType.SUPPORTS

• Never: TransactionAttributeType.NEVER

Ниже приведен пример использования аннотации

@TransactionAttribute(NOT_SUPPORTED)
@Stateful
public class TransactionBean implements Transaction {
...
    @TransactionAttribute(REQUIRES_NEW)
    public void firstMethod() {...}

    @TransactionAttribute(REQUIRED)
    public void secondMethod() {...}

    public void thirdMethod() {...}

    public void fourthMethod() {...}
}

Откат Container-Managed Transaction

Есть два способа откатить container-managed transaction. Первый: контейнер автоматически откатывает транзакцию, если брошен системный exception (в случае application exception откат не произойдет). Второй - можно вызвать метод EJBContext.setRollbackOnly.

Synchronizing a Session Bean’s Instance Variables

Интерфейс SessionSynchronization позволяет stateful session бинам получать синхронизационные уведомлени. Контейнер будет вызывать соответствующие методы (afterBegin, beforeCompletion, and afterCompletion) в нужное время.

Недозволенные методы Container-Managed Transactions

Не следует пользоваться следующими методами:

• commit, setAutoCommit, rollback класса java.sql.Connection

• getUserTransaction класса javax.ejb.EJBContext

• любыми методами javax.transaction.UserTransaction

Если они вам необходимы, пользуйтеся application-managed transactions.

Bean-Managed Transactions

При использовании bean-managed transaction demarcation, вы должны явно определять границы транзакции. Главное преимущество по сравнению с container-managed является возможность определять несколько транзакций в одном методе.

Ниже приведен псевдокод примера

begin transaction
...
 update table-a
...
 if (condition-x)
   commit transaction
 else if (condition-y)
   update table-b
   commit transaction
 else
   rollback transaction
   begin transaction
   update table-c
   commit transaction

Во время кодирования application-managed transaction, необходимо решить что использовать: JDBC или JTA транзакции.

JTA транзакции

JTA позволяет управлять транзакциями независимо от реализации. Сервер приложений реализует управление транзакциями с помощью Java Transaction Service (JTS).

Преимущество JTA в том, что можно охватывать несколько баз данных различных вендоров. Однако, Java EE transaction manager имеет ограничение: встроенные (nested) транзакции не поддерживаются. Другими словами, нельзя создать транзакцию для экземпляра, пока предыдущая не закончена.

Для определения границ транзакции вызываются методы begin, commit, and rollbac интерфейса javax.transaction.UserTransaction.

Возврат без коммита

В stateless session бинах с bean-managed transactions метод должен закоммитить или откатить транзакцию до возврата значения. Но stateful session bean не имеет такой обязанности.
В stateful session bean ассоциация бина и транзакции сохраняется между вызовами.

Запрещенные методы в Bean-Managed Transactions

Не вызывайте методы getRollbackOnly and setRollbackOnly интерфейса EJBContext, вместо этого используйте getStatus и rollback интерфейса UserTransaction.

Таймаут транзакции

Длч container-managed transactions можно использовать Admin Console для определения таймаута транзакций.

1. В Admin Console -> Configuration -> Transaction Service.

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

Для bean-managed используйте метод UserTransaction.setTransactionTimeout

Обновление нескольких баз данных

Бинам разрешается обновлять несколько баз данных в пределах одной транзакции. Ниже на рисунках показаны два возможных сценария.

На рис. 33-2 все обновления происходят в одной транзации.

Figure 33-2

Во втором случае (рис. 33-3), transaction managers Java EE сервера также гарантирует, что все обновления произойдут в пределах одной транзакции.

Figure 33-3

Транзакции в Web компонентах

Вы можете определять транзакции в web-компонентах использую java.sql.Connection или javax.transaction.UserTransaction. Использование аналогично использованию в session beans.

Критерии

Столкнулся с выборкой данных по критериям.

Если необходимо отобрать объекты по нескольким полям, поступаем просто:

Session session = (Session) em.getDelegate();
Criteria criteria = session.createCriteria(Payment.class);

criteria.addOrder(Order.desc("paymentDate"));
criteria.add(Restrictions.eq("id", request.getPaymentId()));
criteria.add(Restrictions.ge("paymentDate", request.getSince()));
criteria.add(Restrictions.le("paymentDate", request.getTill()));

return criteria.list();

Все просто, все понятно.
Но если необходимо отобрать записи не по полю объекта, а по полю объекта, на который ссылается данный?

В этом случае правильное рещение выглядит так (допустим, что entity Payment имеет ссылку на entity Account)

criteria = criteria.createCriteria(Payment.class);

// добавляем отбор по полям класса Payment

// Опускаемся к объекту Account
criteria = criteria.createCriteria("Account");

// Добавляем отбор по полям Account
criteria.add(Expression.eq("accountNumber", 123));

Но если нужно сделать отбор по embedded полю, поступить следует так:

criteria.add(Restrictions.eq("account.accountNumber", 123));