Source Allies Blog » Hibernate

Hibernate Date vs Timestamp

David Kessler — Thu, 02 Feb 2012 20:24:21 +0000

I encountered a subtle hibernate mapping issue involving Dates and Timestamps. The following test recreates this issue.

package com.sourceallies.logging;
 
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;
 
import java.sql.Timestamp;
import java.util.Calendar;
import java.util.Date;
import java.util.List;
 
import javax.annotation.Resource;
 
import org.apache.commons.lang.time.DateUtils;
import org.hibernate.Criteria;
import org.hibernate.SessionFactory;
import org.hibernate.classic.Session;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.transaction.TransactionConfiguration;
import org.springframework.transaction.annotation.Transactional;
 
import com.sourceallies.Person;
 
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
@TransactionConfiguration(defaultRollback=false)
public class HibernateDateTimeTest {
 
	@Resource
	private SessionFactory sessionFactory;
 
	private Session currentSession;
 
	private Date birthDateWithTime;
	private Date birthDateWithoutTime;
	private Date createDate;
	private Date modifyDate;
 
	@Before
	public void setUp() throws Exception{
		currentSession = sessionFactory.getCurrentSession();
		birthDateWithTime = new Date();
		birthDateWithoutTime = DateUtils.truncate(birthDateWithTime, Calendar.DATE);
		createDate = new Date();
		modifyDate = new Date();
	}
 
	@Test
	@Transactional
	public void testSave(){
		Person person = new Person("testFirst", "testLast", 
                      birthDateWithTime, createDate, modifyDate);
 
		assertFalse(person.getBirthDate() instanceof Timestamp);
		assertFalse(person.getCreateDate() instanceof Timestamp);
		assertFalse(person.getModifyDate() instanceof Timestamp);
 
		saveOrUpdate(person);
	}
 
	@Test
	@Transactional
	public void testFind(){
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
		Person foundPerson = people.get(0);
 
		assertTrue(foundPerson.getBirthDate() instanceof Date);
		assertTrue(foundPerson.getCreateDate() instanceof Timestamp);
		assertTrue(foundPerson.getModifyDate() instanceof Timestamp);
 
		assertFalse(foundPerson.getBirthDate().equals(birthDateWithTime));
		assertTrue(foundPerson.getBirthDate().equals(birthDateWithoutTime));
		assertFalse(foundPerson.getCreateDate().equals(createDate));
		assertFalse(foundPerson.getModifyDate().equals(modifyDate));
	}
 
	public void saveOrUpdate(Person person) {
		currentSession.saveOrUpdate(person);
		currentSession.flush();
	}
 
	@SuppressWarnings("unchecked")
	private List<Person> findAll() {
		Criteria criteria = currentSession.createCriteria(Person.class);
		List<Person> people = criteria.list();
		return people;
	}
}

Here is the mapping for person.

...
@Entity
public class Person {
 
	@Id
	@GeneratedValue(strategy=GenerationType.AUTO)
	private Long id = -1L;
 
	@Column
	private String firstName;
 
	@Column
	private String lastName;
 
	@Column
	@Type(type="date")
	private Date birthDate;
 
	@Column
	@Type(type="timestamp")
	private Date createDate;
 
	@Column
	private Date modifyDate;
	...
}

There are three Date fields: ‘birthdate’, ‘createDate’, and ‘modifyDate’. The fields ‘birthDate’ and ‘createDate’ have a specified Type. The field ‘modifyDate’ however, does not have a specified Type. The generated SQL from Hibernate is as follows.

CREATE TABLE Person (id bigint generated BY DEFAULT AS identity (start WITH 1), 
birthDate date, createDate timestamp, firstName varchar(255), 
lastName varchar(255), modifyDate timestamp, PRIMARY KEY (id))

We see that Hibernate created ‘birthDate’ as a ‘Date’ and the other two were created as a ‘Timestamp’. The primary difference between ‘Date’ and ‘Timestamp’ in SQL is that ‘Timestamp’ holds the date and time while the ‘Date’ only holds the date.

At first glance this is not a big deal, but let’s take a closer look at the test.

 
	@Test
	@Transactional
	public void testSave(){
		Person person = new Person("testFirst", "testLast", 
                           birthDateWithTime, createDate, modifyDate);
 
		assertFalse(person.getBirthDate() instanceof Timestamp);
		assertFalse(person.getCreateDate() instanceof Timestamp);
		assertFalse(person.getModifyDate() instanceof Timestamp);
 
		saveOrUpdate(person);
	}

Person is created with three Dates that all include date and time values.

	@Test
	@Transactional
	public void testFind(){
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
		Person foundPerson = people.get(0);
 
		assertTrue(foundPerson.getBirthDate() instanceof Date);
		assertTrue(foundPerson.getCreateDate() instanceof Timestamp);
		assertTrue(foundPerson.getModifyDate() instanceof Timestamp);
 
		assertFalse(foundPerson.getBirthDate().equals(birthDateWithTime));
		assertTrue(foundPerson.getBirthDate().equals(birthDateWithoutTime));
		assertFalse(foundPerson.getCreateDate().equals(createDate));
		assertFalse(foundPerson.getModifyDate().equals(modifyDate));
	}

When Hibernate retrieves a Person from the database the ‘createDate’ and ‘modifyDate’ have been converted to Timestamps. At first glance this doesn’t appear to be a big deal. java.sql.Timestamp extends java.util.Date. But why are they not equal. I found a helpful answer to this question in Effective Java (2nd Edition) page 41.

There are some classes in the Java platform libraries that do extend an instantiable
class and add a value component. For example, java.sql.Timestamp
extends java.util.Date and adds a nanoseconds field. The equals implementation
for Timestamp does violate symmetry and can cause erratic behavior if
Timestamp and Date objects are used in the same collection or are otherwise intermixed.
The Timestamp class has a disclaimer cautioning programmers against
mixing dates and timestamps. While you won’t get into trouble as long as you
keep them separate, there’s nothing to prevent you from mixing them, and the
resulting errors can be hard to debug. This behavior of the Timestamp class was a
mistake and should not be emulated. (Bloch, Effective Java, 2nd Ed.)

If you want to read more about ‘equals’ read chapter 3, Item 8 in Effective Java (2nd Edition). Apart from a hack there are two primary ways to solve this issue. The first way involves typing ‘createDate’ and ‘modifyDate’ to Timestamp.

	...
	@Column
	@Type(type="date")
	private Date birthDate;
 
	@Column
	private Timestamp createDate;
 
	@Column
	private Timestamp modifyDate;
        ...

The second approach uses a custom UserType. Here is a custom UserType that converts Timestamp to Date and vise versa. There is a side effect with this solution. Converting Timestamp to Date drops the nanosecond precision. If this is not acceptable then the previous solution should be used.

package com.sourceallies;
 
import java.io.Serializable;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Timestamp;
import java.sql.Types;
import java.util.Date;
 
import org.hibernate.HibernateException;
import org.hibernate.usertype.UserType;
 
public class DateTimeUserType  implements UserType {
 
	@Override
	public int[] sqlTypes() {
		 return new int[]{Types.TIMESTAMP};
	}
 
	@SuppressWarnings("rawtypes")
	@Override
	public Class returnedClass() {
		return Date.class;
	}
 
	@Override
	public boolean equals(Object x, Object y) throws HibernateException {
		 return x == y || !(x == null || y == null) && x.equals(y);
	}
 
	@Override
	public int hashCode(Object x) throws HibernateException {
		return x.hashCode();
	}
 
	@Override
	public Object nullSafeGet(ResultSet rs, String[] names, Object owner)
			throws HibernateException, SQLException {
		Timestamp timestamp = rs.getTimestamp(names[0]);
        if (rs.wasNull()) {
            return null;
        }
        return new Date(timestamp.getTime());
	}
 
	@Override
	public void nullSafeSet(PreparedStatement st, Object value, int index)
			throws HibernateException, SQLException {
        if (value == null) {
            st.setNull(index, Types.TIMESTAMP);
        }
        else {
            Date date = (Date) value;
            Timestamp timestamp = new Timestamp(date.getTime());
            st.setTimestamp(index, timestamp);
        }
	}
 
	@Override
	public Object deepCopy(Object value) throws HibernateException {
		return value;
	}
 
	@Override
	public boolean isMutable() {
		return false;
	}
 
	@Override
	public Serializable disassemble(Object value) throws HibernateException {
		 return (Serializable) value;
	}
 
	@Override
	public Object assemble(Serializable cached, Object owner)
			throws HibernateException {
		return cached;
	}
 
	@Override
	public Object replace(Object original, Object target, Object owner)
			throws HibernateException {
		return original;
	}
}

Here is the way to use it in the Person class.

@Entity
@TypeDefs({
		@TypeDef(name="dateTimeUserType", typeClass=DateTimeUserType.class)
})
public class Person {
	...
	@Column
	@Type(type="date")
	private Date birthDate;
 
	@Column
	@Type(type="dateTimeUserType")
	private Date createDate;
 
	@Column
	@Type(type="dateTimeUserType")
	private Date modifyDate;
        ...

Either of these solutions will prevent the ‘equals’ issue that we encountered before. This issue is not a Hibernate issue it is truly a Java issue as is stated in Effective Java (2nd Edition). Hibernate can be challenging enough without these subtle issues that are easy to miss until a bug is reported.

Here is the complete code. Hibernate Logging Zip .

Hibernate Logging

David Kessler — Mon, 30 Jan 2012 14:54:22 +0000

Through the years I’ve encountered a recurring requirement. Clients need to log changes to the database for auditing and legal purposes. To satisfy this requirement you could add logging to every save/update/delete call in your code. Or better yet, you could create an aspect that wraps these calls. While these would certainly work Hibernate provides a convenient interceptor.

In this article I will show you how to add a simple logger to Hibernate.

Start with a Test

As an avid TDD practitioner I will of coarse start with a test. Here is the final version of the test that I used to drive my code.

package com.sourceallies.logging;
 
import static org.junit.Assert.assertEquals;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.verifyNoMoreInteractions;
 
import java.util.Date;
import java.util.List;
 
import javax.annotation.Resource;
 
import org.apache.commons.logging.Log;
import org.hibernate.Criteria;
import org.hibernate.SessionFactory;
import org.hibernate.classic.Session;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.transaction.annotation.Transactional;
 
import com.sourceallies.Person;
 
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class HibernateInterceptorTest {
 
	@Resource
	private SessionFactory sessionFactory;
 
	@Resource
	private HibernateInterceptor hibernateInterceptor;
 
	private Session currentSession;
 
	private Log logger;
 
	private static final Date NOW = new Date();
 
	@Before
	public void setUp(){
		logger = mock(Log.class);
		currentSession = sessionFactory.getCurrentSession();
		hibernateInterceptor.setLogger(logger);
	}
 
	@Test
	@Transactional
	public void testSaveLogging(){
		saveOrUpdate(createPerson());
 
		assertEquals(1, findAll().size());
 
		verify(logger).info("Saving Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");
		verifyNoMoreInteractions(logger);
	}
 
	@Test
	@Transactional
	public void testUpdateLogging(){
		saveOrUpdate(createPerson());
 
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
 
		Person firstPerson = people.get(0);
		firstPerson.setFirstName("testFirst2");
 
		saveOrUpdate(firstPerson);
 
		currentSession.flush();
 
		verify(logger).info("Saving Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");	
		verify(logger).info("Updating Person [firstName=testFirst2, lastName=testLast, birthDate=" + NOW + "].");	
		verifyNoMoreInteractions(logger);
	}
 
	@Test
	@Transactional
	public void testDeleteLogging(){
		saveOrUpdate(createPerson());
 
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
 
		Person firstPerson = people.get(0);
 
		delete(firstPerson);
 
		currentSession.flush();
 
		verify(logger).info("Saving Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");	
		verify(logger).info("Deleting Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");	
		verifyNoMoreInteractions(logger);
	}
 
	@Transactional
	public void saveOrUpdate(Person person) {
		currentSession.saveOrUpdate(person);
		currentSession.flush();
	}
 
	@Transactional
	public void delete(Person person) {
		currentSession.delete(person);
	}
 
	@SuppressWarnings("unchecked")
	private List<Person> findAll() {
		Criteria criteria = currentSession.createCriteria(Person.class);
		List<Person> people = criteria.list();
		return people;
	}
 
 
	private Person createPerson() {
		Person person = new Person("testFirst", "testLast", NOW);
		return person;
	}
}

I used a mock logger to gather information from the interceptor.

Spring Configuration

Here is the configuration required for the interceptor.

 
	 id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
                ...
		 name="dataSource" ref="dataSource" />
		 name="entityInterceptor" ref="hibernateInterceptor"/>
	>
 
	 id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
		 name="sessionFactory" ref="sessionFactory" />
	>
         ...	
	 base-package="com.sourceallies" />
        ...

The ‘entityInterceptor’ property on the ’sessionFactory’ takes a Hibernate interceptor.

Entity

@Entity
public class Person {
 
	@Id
	@GeneratedValue(strategy=GenerationType.AUTO)
	private Long id = -1L;
 
	@Column
	private String firstName;
 
	@Column
	private String lastName;
 
	@Column
	private Date birthDate;
...
	@Override
	public String toString() {
		return "Person [firstName=" + firstName + ", lastName="
				+ lastName + ", birthDate=" + birthDate + "]";
	}
}

For this example you need to implement the ‘toString’ method on the entity being logged.

Interceptor

Here is the interceptor code.

package com.sourceallies.logging;
 
import java.io.Serializable;
 
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.hibernate.EmptyInterceptor;
import org.hibernate.type.Type;
import org.springframework.stereotype.Component;
 
@Component
public class HibernateInterceptor extends EmptyInterceptor {
 
	private static final long serialVersionUID = 1L;
	private Log logger = LogFactory.getLog(HibernateInterceptor.class);
 
	@Override
	public void onDelete(Object entity, Serializable id, Object[] state,
			String[] propertyNames, Type[] types) {
		log("Deleting", id, entity);
		super.onDelete(entity, id, state, propertyNames, types);
	}
 
	@Override
	public boolean onFlushDirty(Object entity, Serializable id,
			Object[] currentState, Object[] previousState,
			String[] propertyNames, Type[] types) {
		log("Updating", id, entity);
		return super.onFlushDirty(entity, id, currentState, previousState,
				propertyNames, types);
	}
 
	@Override
	public boolean onSave(Object entity, Serializable id, Object[] state,
			String[] propertyNames, Type[] types) {
		log("Saving", id, entity);
		return super.onSave(entity, id, state, propertyNames, types);
	}
 
	protected void setLogger(Log logger) {
		this.logger = logger;
	}
 
	private void log(String action, Serializable id, Object entity) {
		logger.info(action + " " + entity + ".");
	}
}

While the ‘onSave’ and ‘onDelete’ methods are clearly named the ‘onUpdate’ method appears to be missing. With a little research it quickly becomes obvious that ‘onFlushDirty’ is used for updates.

Logging database activity is this simple.

Here is the complete code. Hibernate Logging Zip

Rethinking the DAO-Service layer relationship

Tim Bierbaum — Fri, 08 Apr 2011 17:34:25 +0000

Lately I have been thinking that the standard service-calling-the-dao-layer architecture hasn’t been working out as well as I would hope. The applications I have been working on have been using Spring and Hibernate with a dao object per model object. While this does provide a good separation between the two, I have been finding it increasingly difficult to write good tests for the service layer as the project matures. Past experience has shown that if writing tests is difficult, then it just isn’t done. Follow along as I think about possible ways to address this issue.

Let’s look at what I consider to be the ’standard’ service layer object.

public class ServiceExample1 {
	private FooDAO fooDAO;
	private BarDAO barDAO;
 
	public void searchForFooAndBar() {
		//
		// do some stuff
		//
 
		fooDAO.searchForFoo();
 
		//
		// do some more stuff
		// 
 
		barDAO.searchForBar();
 
		//
		// finish up doing stuff
		//
	}
 
	public void createANewFoo(Foo foo) {
		fooDAO.createFoo(foo);
	}
	public void createANewBar(Bar bar) {
		barDAO.createBar(bar);
	}
}

A couple of methods are defined, and they use two difference dao objects. Writing a test for the searchForFooAndBar method would currently involve providing alternative implementations for both the FooDAO and BarDAO objects. While this initially wouldn’t be too difficulty, it is easy to imagine how the number of dao dependencies could grow as the project goes on. It could also cause problems since we wouldn’t know which methods in the dao needed to be stubbed out or mocked for testing. I also worry that it would be too easy to test implementation instead of behavior. A test failure would be reported if the service changed which dao methods were called.

Another issue I’ve run into is not knowing which dao’s are involved in a method when writing the test. My initial thought was to not have the service object maintain references to the dao objects, but instead have each method require them as method parameters.

public class ServiceExample2 {
	public void searchForFooAndBar(FooDAO fooDAO, BarDAO barDAO) {
		//
		// do some stuff
		//
 
		fooDAO.searchForFoo();
 
		//
		// do some more stuff
		// 
 
		barDAO.searchForBar();
 
		//
		// finish up doing stuff
		//
	}
 
	public void createANewFoo(FooDAO fooDAO, Foo foo) {
		fooDAO.createFoo(foo);
	}
	public void createANewBar(BarDAO barDAO, Bar bar) {
		barDAO.createBar(bar);
	}
}

Looking over this code, I didn’t care for it from the start. Maybe if the service layer objects were finer grained. Instead of three methods in the service from our first example, maybe there should be 3 service classes.

	public void searchForFooAndBar() {
		//
		// do some stuff
		//
 
		fooDAO.searchForFoo();
 
		//
		// do some more stuff
		// 
 
		barDAO.searchForBar();
 
		//
		// finish up doing stuff
		//
	}

I think this would help fix the problem of having too many dao references, but I still wasn’t sure I liked the dependency on the dao’s themselves. That brought me to the final solution I thought of, which involves creating an interface for each method that defines the operations it requires to be provided.

public interface FooCreationAdapter {
	public void createFoo(Foo foo);
}
public interface BarCreationAdapter {
	public void createBar(Bar bar);
}
public interface SearchAdapter {
	public void searchForFoo();
	public void searchForBar();
}
public class Service {
	public void searchForFooAndBar(SearchAdapter searchAdapter) {
		//
		// do some stuff
		//
 
		searchAdapter.searchForFoo();
 
		//
		// do some more stuff
		// 
 
		searchAdapter.searchForBar();
 
		//
		// finish up doing stuff
		//
	}
 
	public void createANewFoo(FooCreationAdapter adapter, Foo foo) {
		adapter.createFoo(foo);
	}
	public void createANewBar(BarCreationAdapter adapter, Bar bar) {
		adapter.createBar(bar);
	}
}

While I feel this is the cleanest solution that would be the easiest to test, I really don’t think it is practical on a project level. Does anyone have a solution that has worked well for them?

MySQL Master/Slave configuration with EJB3 and JPA

Vaithi Subramanian — Fri, 26 Mar 2010 18:33:19 +0000

Well this turned out to be quite an exercise.

The goal: scalable reads with MySQL in master-slave configuration, writing to the master, and reading from N slaves, load balanced in round-robin fashion (or something).

The problem: using JPA (Java Persistence API) instead of direct JDBC calls. Turns out the MySQL ReplicationDriver (used to load balance reads to slaves and send writes to the master) relies on the readOnly state of the Connection in order to decide whether it’s a read or a write. With direct JDBC calls, I could get the Connection and toggle the readOnly state as needed.

However, buried under JPA and EntityManager and so on, there’s no way to do that. So I looked into other solutions (LBPool, for instance), but nothing out there seems to be intended for JPA environment.

So I had to do it myself… in digging around in the MySQL Connector/J source, I discovered the loadbalance option, intended for use w/ MySQL Cluster, because in that environment, you don’t need to distinguish between master and slave, they’re all just nodes.

The loadbalance option wouldn’t work directly for me, of course, because I don’t want to load balance writes, just reads.

Soulution to the problem is to use two data sources, one for reads, and the other for writes, I can stick the read data source behind all my “fetch stuff” APIs, and use the write data source for everything else. Then I can use the loadbalance option for the read data source, because I know for certain I’m never sending it any writes.

I am currently using Jboss 4.2.1 GA here my mysql-ds.xml

>
  >
    >MasterA>
    >jdbc:mysql://masterDB/databasename>
    >com.mysql.jdbc.ReplicationDriver>
    >username>
    >password>
    >10>
    
    >50>
    >10>
    >com.mysql.jdbc.integration.jboss.ExtendedMysqlExceptionSorter>
    >com.mysql.jdbc.integration.jboss.MysqlValidConnectionChecker>
    
    >
      >mySQL>
    >
  >
  >
    >SlaveA>
    >jdbc:mysql://slaveA,slaveB/databasename>
    >com.mysql.jdbc.ReplicationDriver>
    >username>
    >password>
    >10>
    
    >50>
    >10>
    >com.mysql.jdbc.integration.jboss.ExtendedMysqlExceptionSorter>
    >com.mysql.jdbc.integration.jboss.MysqlValidConnectionChecker>
    
    >
      >mySQL>
    >
  >
>

Persistence.xml for the JTA datasources.

 version="1.0" encoding="UTF-8"?>
			 version="1.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 persistence_1_0.xsd">
 name="Master">
	>org.hibernate.ejb.HibernatePersistence>
	>
		java:/MasterA
	>
	>
		 name="hibernate.dialect" value="org.hibernate.dialect.MySQL5Dialect" />			
		 name="hibernate.connection.readOnly" value="true" /> 	>
>
 name="Slave">
	>org.hibernate.ejb.HibernatePersistence>
	>
		java:/SlaveA
	>
	>
		 name="hibernate.dialect" value="org.hibernate.dialect.MySQL5Dialect" />			
		 name="hibernate.connection.readOnly" value="true" /> 	
>
>
>

For normal JDBC connections read only state can changed like the following code.

public static void main(String[] args) throws Exception {
    ReplicationDriver driver = new ReplicationDriver();
 
    Properties props = new Properties();
 
    // We want this for failover on the slaves
    props.put("autoReconnect", "true");
 
    // We want to load balance between the slaves
    props.put("roundRobinLoadBalance", "true");
 
    props.put("user", "user");
    props.put("password", "password");
 
    //
    // Looks like a normal MySQL JDBC url, with a
    // comma-separated list of hosts, the first
    // being the 'master', the rest being any number
    // of slaves that the driver will load balance against
    //
 
    Connection conn =
        driver.connect("jdbc:mysql:replication://master,slave1,slave2,slave3/databasename",
            props);
 
    //
    // Perform read/write work on the master
    // by setting the read-only flag to "false"
    //
 
    conn.setReadOnly(false);
    conn.setAutoCommit(false);
    conn.createStatement().executeUpdate("UPDATE some_table ....");
    conn.commit();
 
    //
    // Now, do a query from a slave, the driver automatically picks one
    // from the list
    //
 
    conn.setReadOnly(true);
 
    ResultSet rs =
      conn.createStatement().executeQuery("SELECT a,b FROM alt_table");
 
     .......
  }

Conculsion:
Thus with the help of two data sources I am able to replicate the functionality of Master/Slave Read scalability. If you are using the normal JDBC connection then changing the read-only is as simple as the above code. Hope this will be helpful for someone who needs to setup Replication in the code level.

Hibernate Embeddable Objects

Max Kuipers — Mon, 18 Jan 2010 14:00:06 +0000

Hibernate Embeddable Objects are a really neat way to organize your data model. Especially, if you have the same few columns in a number of different tables, that all pertain to the same thing. The example commonly used is Addresses. You may have a number of tables that each have fields pertaining to address information and you don’t want to have to do all the mappings for each entity again and again. If the column names are the same across each table, you can just add an @Embeddable annotation.

Consider the following example:

@Embeddable
public class Address implements Serializable {
...
   private String lineOne;
   private String lineTwo;
   private String city;
....
   @Column(name = "LINEONE")
   public String getLineOne(){
      return this.lineOne;
   }
...
   @Column(name = "CITY")
   public String getCity(){
      return this.city;
   }
...

This creates address as an embeddable object. Then to actually embed it in your entity, you simply do something like the following:

@Entity
@Table(name= "Person")
public class Person implements Serializable{
...
   private Address address;
...
   @Embedded
   public getAddress() {
      return this.address;
   }
...
}

There is, however, one huge problem with this, especially when working with JSF. If all of the fields in the embeddable object are null for some reason or another, then the embeddable object never actually gets instantiated. There is a solution/hack that works around this – you modify the setter method to look something like the following:

@Entity
@Table(name= "Person")
public class Person implements Serializable{
...
   private Address address;
...
   public void setAddress(Address address){
      if (address != null){
         this.address = address;
      } else {
         this.address = new Address();
      } 
   }
}

It’s not particularly pretty, but it will dry your tears in a pinch. More on this solution can be found here.