via From Spring to Java EE 6 | Java Code Geeks.
I recently worked on a quite complex project mixing many Java EE 6 technologies (such as JPA, JAXB, JMS, JTA, JAX-RS, etc…). For productivity and planning reasons, the prototyped application was designed as a standalone pure Spring application. When the development of the real application started, we re-challenged our initial choice (i.e. Spring v3) and analyzed the interest of switching to a Java EE 6 app server like GlassFish or JBoss.
This finally ended up in two major questions:
- can we do in Java EE 6 everything we can do in Spring ?
- can we do that as easy as in Spring?
Well, I would say that, globally, the answer is: yes we can !
via A beginner’s guide to transaction isolation levels in enterprise Java | Vlad Mihalcea’s Blog.
A relational database strong consistency model is based on ACID transaction properties. In this post we are going to unravel the reasons behind using different transaction isolation levels and various configuration patterns for both resource local and JTA transactions.
via JPA 2.1: Unsynchronized persistence context | Martin’s Developer World.
The JPA version 2.1 brings a new way how to handle the synchronization between the persistence context and the current JTA transaction as well as the resource manager. The term resource manager comes from the Java Transaction API and denotes a component that manipulates one resource (for example a concrete database that is manipulated by using its JDBC driver). Per default a container-managed persistence context is of type
SynchronizationType.SYNCHRONIZED, i.e. this persistence context automatically joins the current JTA transaction and updates to the persistence context are propagated to the underlying resource manager.
By creating a persistence context that is of the new type
SynchronizationType.UNSYNCHRONIZED, the automatic join of the transaction as well as the propgation of updates to the resource manager is disabled. In order to join the current JTA transaction the code has to call the method
joinTransaction() of the
EntityManager. This way the EntityManager’s persistence context gets enlisted in the transaction and is registered for subsequent notifications. Once the transaction is commited or rolled back, the persistence context leaves the transaction and is not attached to any further transaction until the method
joinTransaction() is called once again for a new JTA transaction.
via Unsynchronized Persistence Contexts in JPA 2.1/Java EE 7 (The Aquarium).
One of the more obscure features introduced in JPA 2.1 and Java EE 7 is the unsynchronized persistence context. It’s not too surprising that the community does not seem to discuss it much – it’s really geared towards somewhat an edge case.
Prior to JPA 2.1, the entity manager is always synchronized with the database when a JTA transaction commits. This poses a challenge if you have a multi-step workflow (let’s say in a stateful session bean/CDI conversation/JSF flow) where you want some data to be flushed to the database on transaction commit at a given stage of the workflow but not all – but you do eventually want to synchronize all changes at some other point in the workflow. Non-standard solutions like Seam and the Hibernate flush mode have been the answer in the past to get around this problem. This is now solved in JPA 2.1 via the unsynchronized persistence context. In an unsynchronized persistence context changes are not automatically flushed to the database on transaction commit. Rather, you explicitly join the transaction when you want changes synchronized.
Hantsy Bai does a decent job explaining this through code examples. By far the best explanation of the feature comes from specification lead Linda DeMichiel. Check out minute 11-14 in the short video below (if you are having trouble accessing the embedded video it is available here).
Click to Read: In this tutorial we shall show you how to implement JTA multiple resource transactions in a Tomcat server, using Atomikos Transaction Manager. Atomicos transaction manager provides support for distributed transactions. These are multi-phased transactions, often using multiple databases, that must be committed in a coordinated way. The distributed transactions are described by the
XA governs how a transaction manager (such as Atomikos) can tell a database what work is going on as part of what transaction, and how to conduct the two-phase commit (2PC) protocol at the end of each transaction.