Wednesday 14 September 2011

Configure MySQL datasource in Glassfish 3.1

Part 1 of this article shows how to configure a MySQL datasource in Glassfish 3.1.

Part 2 of this article shows how to test the connection with a standalone Java client program.


Part 1

Assume Glassfish's installation folder is D:\glassfish3\glassfish

Copy mysql-connector-java-xxx-bin.jar to D:\glassfish3\glassfish\lib or D:\glassfish3\glassfish\domains\domain1\lib\ext

Start MySQL server, assume the following settings

URL: jdbc:mysql://localhost:3306/mydb
username: root
password: root

Start Glassfish, go to Admin Console, http://localhost:4848

Resources -> JDBC -> JDBC Connection Pools


Click on 'New'


Click on 'Next'


Scroll down, specify the following properties, and leave others as they are.


User  root
Password  root
Url  jdbc:mysql://localhost:3306/mydb
URL  jdbc:mysql://localhost:3306/mydb

Click on 'Save'

Go to Resources -> JDBC -> JDBC Resources


Click on 'New'


Click on 'OK'


Click on 'Ping' to test.

Part 2

Create a java project in Eclipse (must use JDK 1.6)

import java.sql.Connection;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.sql.DataSource;

public class Main {

    /**
     * @param args
     */
    public static void main(String[] args) 
      throws Exception{
        Context ctx = new InitialContext();
        DataSource ds 
          = (DataSource) ctx.lookup("jdbc/mysql");
        Connection con = ds.getConnection();
        con.close();
    }
}

Add the following two jar files to class path


Note: You can't directly copy gf-client.jar into project's folder. You have to point to the jar file under glassfish\lib

After starting MySQL server and Glassfish Server, we can test the program.

REQUIRED VS REQUIRES_NEW transaction attribute type

This article uses code examples to illustrate the difference between REQUIRED and REQUIRES_NEW transaction attribute type.

Create two entity beans.

@Entity
@Table(name="T_COMPANY")
public class Company{
    
    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    private int id;
    
    @Column(name = "NAME")
    private String name;
    
    public Company() {
        super();
    }
    
    public Company(String name) {
        super();
        this.name = name;
    }
}


@Entity
@Table(name="T_PERSON")
public class Person{
    
    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    private int id;
    
    @Column(name = "NAME")
    private String name;
    
    public Person() {
        super();
    }
    
    public Person(String name) {
        super();
        this.name = name;
    }
}

Create a stateless session bean (companyBean) with a method having REQUIRES_NEW transaction attribute type.

@Stateless(name="companyBean")
@Local(CompanyManager.class)
public class CompanyManagerBean 
    implements CompanyManager {

    @PersistenceContext(unitName="unit")
    private EntityManager em;
    
    @Override
    @TransactionAttribute
    (TransactionAttributeType.REQUIRES_NEW)
    public void save(Company company) {
        em.persist(company);
    }
}

Create another stateless session bean (personBean), and inject the companyBean into the personBean.

@Stateless(name="personBean")
@Local(PersonManager.class)
public class PersonManagerBean 
    implements PersonManager {

    @PersistenceContext(unitName="unit")
    private EntityManager em;
    
    @EJB(beanName="companyBean")
    private CompanyManager companyManager;
    
    @Override
    @TransactionAttribute
    (TransactionAttributeType.REQUIRED)
    public void save(Person person) {
        companyManager.save(new Company("Oracle"));
        em.persist(person);
    }
} 

Write a servlet to test

public class PersonServlet extends HttpServlet {

    @EJB(beanName="personBean")
    private PersonManager personManager = null;
    
    @Override
    protected void doGet(HttpServletRequest req, 
            HttpServletResponse resp)
            throws ServletException, IOException {
        personManager.save(new Person("Mingtao001"));
    }
}

Result:

Table T_COMPANY



Table T_PERSON



Now throw an exception in personBean

@Override
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void save(Person person) {
    companyManager.save(new Company("Oracle"));
    em.persist(person);
    throw new RuntimeException("error!");
}

Clean the table and retest the servlet

Result:

Table T_COMPANY



Table T_PERSON


The SQL that saves the person has been rolled back while the SQL that saves the company was not affected.

Now change the transaction attribute type from REQUIRES_NEW to REQUIRED in companyBean.

@Override
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void save(Company company) {
    em.persist(company);
}

Clean the table and retest the servlet

Result:

Table T_COMPANY



Table T_PERSON



Both SQLs have been rolled back as they are in the same transaction.

Monday 12 September 2011

Transaction VS Extended Persistence Context Type

This article uses code examples to illustrate the difference between TRANSACTION and EXTENDED persistence context type.

Firstly create an entity class

@Entity
@Table(name="T_PERSON")
public class Person{
    
    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    private int id;
    
    @Column(name = "NAME")
    private String name;
    
    public Person() {
        super();
    }
    
    public Person(String name) {
        super();
        this.name = name;
    }
}

Create a TRANSACTION persistence context type in a stateful session bean.

@Stateful(name="transactionPersistenceContextBean")
@Local(TransactionService.class)
public class TransactionPersistenceContextBean 
    implements TransactionService {

    @PersistenceContext(unitName="unit", 
            type=PersistenceContextType.TRANSACTION)
    private EntityManager em;
    
    private Person person;
    
    @Override
    public void save(String name) {
        person = new Person(name);
        em.persist(person);
    }

    @Override
    public void update(String name) {
        person.setName(name);
        em.flush();
    }
}

Create an EXTENDED persistence context type in a stateful session bean.

@Stateful(name="extendedPersistenceContextBean")
@Local(TransactionService.class)
public class ExtendedPersistenceContextBean 
    implements TransactionService {

    @PersistenceContext(unitName="unit", 
            type=PersistenceContextType.EXTENDED)
    private EntityManager em;
    
    private Person person;
    
    @Override
    public void save(String name) {
        person = new Person(name);
        em.persist(person);
    }

    @Override
    public void update(String name) {
        person.setName(name);
        em.flush();
    }
}

Create a servlet to test

public class PersistenceContextServlet
   extends HttpServlet {
    
    @EJB(beanName="transactionPersistenceContextBean")
    //@EJB(beanName="extendedPersistenceContextBean")
    private TransactionService service;
    
    @Override
    protected void doGet(HttpServletRequest req, 
            HttpServletResponse resp)
            throws ServletException, IOException {
        service.save("abcde");
        service.update("defgh");
    }
}

The result for TRANSACTION Persistence Context


The result for EXTENDED Persistence Context


For TRANSACTION Persistence Context type, when the save method is complete, person instance is detached. So when the update method is invoked, person instance is not associated with the database session. So any changes made to person instance cannot be synchronized to the database.

For EXTENDED Persistence Context type, when the save method is complete, person instance is still managed by the database session. So when the update method is invoked, any changes made to person instance will be synchronized to the database.

So how can we update person instance in the case of TRANSACTION Persistence Context type?

By merging person instance so that person instance is managed by the database session.

public void update(String name) {
    person = em.merge(person);
    person.setName(name);
    em.flush();
}

The result:


Note: Only the returned object by merge method is associated with the database session.

e.g. if the update method is changed to

public void update(String name) {
    em.merge(person);
    person.setName(name);
    em.flush();
} 

The result:


This is because the above person instance is not managed by database session.

Saturday 10 September 2011

EJB Generic DAO

Step 1: Declare a GenericDao interface

public interface GenericDao<T> {
    public void save(T entity);
    public void update(T entity);
    public T find(Serializable entityId);
    public void delete(Serializable... ids);
}

Step 2: Create an abstract GenericDaoSupport Class

@SuppressWarnings("unchecked")
public abstract class GenericDaoSupport<T>
    implements GenericDao<T> {

    private Class<T> entityClass 
        = GenericsUtils.getSuperClassGenericType
        (this.getClass());
    
    @PersistenceContext(unitName="ejbPU")
    protected EntityManager em;
    
    public void delete(Serializable... ids) {
        for(Serializable id: ids){
            em.remove(em.getReference(entityClass, id));
        }
    }

    public T find(Serializable entityId) {
        return em.find(entityClass, entityId);
    }

    public void save(T entity) {
        em.persist(entity);
    }

    public void update(T entity) {
        em.merge(entity);
    }
}

We need a utility class here to get the entity type
e.g. For GenericDaoSupport<Order>,
GenericsUtils.getSuperClassGenericType() will return Order class

public class GenericsUtils {
    
    @SuppressWarnings("unchecked")
    public static Class getSuperClassGenericType(Class clazz){
        return getSuperClassGenericType(clazz, 0);
    }
    
    /**
     * 
     * @param clazz
     * @param index
     * @return
     */
    @SuppressWarnings("unchecked")
    public static Class getSuperClassGenericType
        (Class clazz, int index){
        //Get super class's generic Type
        //e.g. GenericDaoSupport<Order>
        Type genericType = clazz.getGenericSuperclass();
        //If not a parameterized type, e.g. GenericDaoSupport
        if (!(genericType instanceof ParameterizedType)){
            //Just return the Object class
            return Object.class;
        }
        //Get actual types
        //e.g. for GenericDaoSupport<Order, Customer, Item>
        //params = {Order, Customer, Item}
        Type[] params = ((ParameterizedType)genericType)
            .getActualTypeArguments();
        if (index >= params.length || index < 0){
            throw new IllegalArgumentException
            ("The index is invalid:"+index);
        }
        return (Class)params[index];
    }
}

Step 3: Create an entity

@Entity
@Table(name="T_ORDER")
public class Order implements Serializable{
    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    private int id;
    
    @Column(name="CREATE_DATE")
    @Temporal(TemporalType.DATE)
    private Date createDate = new Date();

    public int getId() {
        return id;
    }

    public Date getCreateDate() {
        return createDate;
    }    
}

Step 4: Declare an enity Dao interface

public interface OrderDao 
    extends GenericDao<Order> {
}

Step 5: Implement the entity Dao interface

@Stateless(name="orderDao")
@Remote(OrderDao.class)
public class OrderDaoImpl 
    extends GenericDaoSupport<Order> 
    implements OrderDao {
}

So whenever we need to create a new entity Dao, we just need to have it extend GenericDaoSupport so that we don't have to duplicate the code of CRUD operations.