Skip to main content

Java Transactions



ACID:
Atomicity: Either should commit all rollback all of its updates in a single unit of work.
Consistency: database should never be left in inconsistent state
Isolation: How protected is uncommitted changes from other transactions, isolation decreases concurrency.
Durability: changes are permanent.

interfaces
UserTransaction begin(), commit(), rollback(), getStatus()
TransactionManager suspend(), resume(), setRollbackOnly(),
Status ACTIVE, COMMITTED, COMMITING, MARKED_ROLLBACK, NO_TRANSACTION, PREPARED, PREPARING, ROLLEDBACK, ROLLING_BACK, UNKNOWN.

Transaction Models

1. Local
2. Programatic
3. Declarative

Local Transaction Model:
Resource manager manages transactions. Developer manages connections.
e.g.
conn.setAutoCommit(false);
try {
  stmt.executeUpdate(sql1);
  stmt.executeUpdate(sql1);
  conn.commit()
} catch (Exception e) {
  conn.rollback();
}

Programatic Transaction Model
Uses JTA, developer uses UserTransaction begin(), commit() or rollback().
UserTransaction tx
tx.begin()
tx.commit()
tx.rollback()
Doesn't scale if calling one service from other.

Declarative Transaction Model:
CMT, container's manages transactions, developer should tell Spring, EJB where to being etc.
@Transactional

Patterns

1. Client Owner Transaction Design Pattern
Forces:
1. The client requires multiple remote calls to fulfill a single business request.
2. ACID properties must be maintained
3. Domain service objects are fine-grained and no aggregate service exist.
4. Not possible to re-architect.
Solution:
client is responsible for transactions
Consequences:
client should use programmatic tx or declarative if spring is used.
spring doesn't support remote tx

2. Domain Service Owner Transaction Design Pattern
typical web app

3. Server Delegate Owner Transaction Design Pattern
forces:
Command Pattern or Server Delegate Pattern
client makes a single request to a server delegate
command processor is the entry point









Comments

Popular posts from this blog

Access multiple Databases in JPA

According to JPA specification we can define multiple "persistence-unit" elements (i.e. like below) in persistence.xml file and can easily refer them inside Dao layers as this. public class PolarDaoImpl {     @PersistenceContext(unitName="PolarPU")     protected EntityManager entityManager; -- } public class BearDaoImpl {     @PersistenceContext(unitName="BearPU")     protected EntityManager entityManager; -- } Checkout sample persistence.xml <?xml version="1.0" encoding="UTF-8"?> <persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">     <!-- Database 1 -->     <persistence-unit name="PolarPU" transaction-type="RESOURCE_LOCAL">         <

JPA 2 new feature @ElementCollection explained

@ElementCollection is new annotation introduced in JPA 2.0, This will help us get rid of One-Many and Many-One shitty syntax. Example 1: Stores list of Strings in an Entity @Entity public class Users implements Serializable {     private static final long serialVersionUID = 1L;     @Id     @GeneratedValue(strategy = GenerationType.AUTO)     private Long id;     @ElementCollection     private List<String> certifications = new ArrayList <String> ();     public Long getId() {         return id;     }     public void setId(Long id) {         this.id = id;     }     public List <String> getCertifications() {         return certifications;     }     public void setCertifications(List <String> certifications) {         this.certifications = certifications;     } .. }         Users u = new Users();         u.getCertifications().add("Sun Certified Java Programmer");         em.persist(u); Generated Tables    Users    Co

Reuse JPA Entities as DTO

Note : Major design advantages of JPA Entities are they can detached and used across tiers and networks and later can by merged. Checkout this new way of querying entities in JPA 2.0 String ql = " SELECT new prepclass2.Employee (e.firstname, e.lastname) FROM Employee e "; List<Employee> dtos = em.createQuery(ql).getResultList(); The above query loads all Employee entities but with subset of data i.e. firstname, lastname. Employee entity looks like this. @Entity @Table(name="emp") public class Employee implements Serializable {     private static final long serialVersionUID = 1L;     @Id     @GeneratedValue(strategy = GenerationType.AUTO)     private Long id;     @Column     private String firstname;     @Column     private String lastname;     @Column     private String username;     @Column     private String street;     @Column     private String city;     @Column     private String state;     @Column     private String zipc