Hibernate – Fetching Strategies Examples

Hibernate has few fetching strategies to optimize the Hibernate generated select statement, so that it can be as efficient as possible. The fetching strategy is declared in the mapping relationship to define how Hibernate fetch its related collections and entities.

Fetching Strategies

There are four fetching strategies

• fetch-”join” = Disable the lazy loading, always load all the collections and entities.
• fetch-”select” (default) = Lazy load all the collections and entities.
• batch-size=”N” = Fetching up to ‘N’ collections or entities, *Not record*.
• fetch-”subselect” = Group its collection into a sub select statement.

For detail explanation, you can check on the Hibernate documentation.

Fetching Strategies Examples

Here’s a “one-to-many relationship” example for the fetching strategies demonstration. A stock is belong to many stock daily records. <hibernate-mapping> <class name="com.mkyong.common.Stock" table="stock"> <set name="stockDailyRecords" cascade="all" inverse="true" table="stock_daily_record" batch-size="10" fetch="select"> <key> <column name="STOCK_ID" not-null="true" /> </key> <one-to-many class="com.mkyong.common.StockDailyRecord" /> </set> </class> </hibernate-mapping>
... @Entity @Table(name = "stock", catalog = "mkyong") public class Stock implements Serializable{ ... @OneToMany(fetch = FetchType.LAZY, mappedBy = "stock") @Cascade(CascadeType.ALL) @Fetch(FetchMode.SELECT) @BatchSize(size = 10) public Set<stockdailyrecord> getStockDailyRecords() { return this.stockDailyRecords; } ... }
Lets explore how fetch strategies affect the Hibernate generated SQL statement.

Fetch=”Select” Or @Fetch(FetchMode.SELECT)

This is the default fetching strategy. it enabled the lazy loading of all it’s related collections.
//call select from stock Stock stock = (Stock)session.get(Stock.class, 114); Set sets = stock.getStockDailyRecords(); //call select from stock_daily_record for ( Iterator iter = sets.iterator();iter.hasNext(); ) { StockDailyRecord sdr = (StockDailyRecord) iter.next(); System.out.println(sdr.getDailyRecordId()); System.out.println(sdr.getDate()); }
Output:

Hibernate: 
    select ...from mkyong.stock
    where stock0_.STOCK_ID=?
 
Hibernate: 
    select ...from mkyong.stock_daily_record
    where stockdaily0_.STOCK_ID=?

Hibernate generated two select statements
1. Select statement to retrieve the Stock records -session.get(Stock.class, 114)
2. Select its related collections – sets.iterator()

Fetch=”Join” Or @Fetch(FetchMode.JOIN)

The “join” fetching strategy will disabled the lazy loading of all it’s related collections.
//call select from stock and stock_daily_record Stock stock = (Stock)session.get(Stock.class, 114); Set sets = stock.getStockDailyRecords(); //no extra select for ( Iterator iter = sets.iterator();iter.hasNext(); ) { StockDailyRecord sdr = (StockDailyRecord) iter.next(); System.out.println(sdr.getDailyRecordId()); System.out.println(sdr.getDate()); }
Output:

Hibernate: 
    select ...
    from
        mkyong.stock stock0_ 
    left outer join
        mkyong.stock_daily_record stockdaily1_ 
            on stock0_.STOCK_ID=stockdaily1_.STOCK_ID 
    where
        stock0_.STOCK_ID=?

Hibernate generated only one select statement, it retrieve all its related collections when the Stock is initialized. -session.get(Stock.class, 114)
1. Select statement to retrieve the Stock records and outer join its related collections.

Batch-Size=”10″ Or @BatchSize(Size = 10)

This ‘batch size’ fetching strategy is always misunderstanding by many Hibernate developers.
Stock stock = (Stock)session.get(Stock.class, 114); Set sets = stock.getStockDailyRecords(); for ( Iterator iter = sets.iterator();iter.hasNext(); ) { StockDailyRecord sdr = (StockDailyRecord) iter.next(); System.out.println(sdr.getDailyRecordId()); System.out.println(sdr.getDate()); }
What is your expected result, is this per-fetch 10 records from collection? See the Output

Hibernate: 
    select ...from mkyong.stock
    where stock0_.STOCK_ID=?
 
Hibernate: 
    select ...from mkyong.stock_daily_record
    where stockdaily0_.STOCK_ID=?

The batch-size did nothing here, it is not how batch-size work. See this statement.

The batch-size fetching strategy is not define how many records inside in the collections are loaded. Instead, it defines how many collections should be loaded.
— Repeat N times until you remember this statement —

You want to print out all the stock records and its related stock daily records (collections) one by one. List<stock> list = session.createQuery("from Stock").list(); for(Stock stock : list){ Set sets = stock.getStockDailyRecords(); for ( Iterator iter = sets.iterator();iter.hasNext(); ) { StockDailyRecord sdr = (StockDailyRecord) iter.next(); System.out.println(sdr.getDailyRecordId()); System.out.println(sdr.getDate()); } }
No batch-size fetching strategy
Output:

Hibernate: 
    select ...
    from mkyong.stock stock0_
 
Hibernate: 
    select ...
    from mkyong.stock_daily_record stockdaily0_ 
    where stockdaily0_.STOCK_ID=?
 
Hibernate: 
    select ...
    from mkyong.stock_daily_record stockdaily0_ 
    where stockdaily0_.STOCK_ID=?
 
Keep repeat the select statements....depend how many stock records in your table.

If you have 20 stock records in the database, the Hibernate’s default fetching strategies will generate 20+1 select statements and hit the database.

1. Select statement to retrieve all the Stock records.
2. Select its related collection
3. Select its related collection
4. Select its related collection
….
21. Select its related collection
The generated queries are not efficient and caused a serious performance issue.


Enabled the batch-size=’10′ fetching strategy
Let see another example with batch-size=’10′ is enabled.
Output:

Hibernate: 
    select ...
    from mkyong.stock stock0_
 
Hibernate: 
    select ...
    from mkyong.stock_daily_record stockdaily0_ 
    where
        stockdaily0_.STOCK_ID in (
            ?, ?, ?, ?, ?, ?, ?, ?, ?, ?
        )

Now, Hibernate will per-fetch the collections, with a select *in* statement. If you have 20 stock records, it will generate 3 select statements.
1. Select statement to retrieve all the Stock records.
2. Select In statement to per-fetch its related collections (10 collections a time)
3. Select In statement to per-fetch its related collections (next 10 collections a time)

With batch-size enabled, it simplify the select statements from 21 select statements to 3 select statements.

Fetch=”Subselect” Or @Fetch(FetchMode.SUBSELECT)

This fetching strategy is enable all its related collection in a sub select statement.
List<stock> list = session.createQuery("from Stock").list(); for(Stock stock : list){ Set sets = stock.getStockDailyRecords(); for ( Iterator iter = sets.iterator();iter.hasNext(); ) { StockDailyRecord sdr = (StockDailyRecord) iter.next(); System.out.println(sdr.getDailyRecordId()); System.out.println(sdr.getDate()); } }
Output:

Hibernate: 
    select ...
    from mkyong.stock stock0_
 
Hibernate: 
    select ...
    from
        mkyong.stock_daily_record stockdaily0_ 
    where
        stockdaily0_.STOCK_ID in (
            select
                stock0_.STOCK_ID 
            from
                mkyong.stock stock0_
        )

With “subselect” enabled, it will create two select statements.
1. Select statement to retrieve all the Stock records.
2. Select all its related collections in a sub select query.



Conclusion The fetching strategies are highly flexible and a very important tweak to optimize the Hibernate query, but if you used it in a wrong place, it will be a total disaster (You're screwed dude!).

OneToMany Relation with Non PK Columns

While goofing around @ my office my Boss told me about an issue he was facing while trying to map a OneToMany relation, but instead of using the classical PK on one side and FK on the other side, he wanted to define the relationship between tables with nonKey columns. I still don't know why but this situation reminded me when I was having a hard time playing with 1:1 relations.
Anyway the fact is that we need find a workaround for this, and as is well known if you don't define anything on Hibernate (Annotations), by default is going to use the default values, right?

My approach is simple, by just defining after the OneToMany annotation which columns I'll join, in order to get this Set. @OneToMany(cascade=CascadeType.ALL, fetch=FetchType.LAZY) @JoinColumn(name="", referencedColumnName="") public Set<Child> getMySet() { return mySet; } Probably my Child table has a PK which doesn't have anything to do with the column I'm using to do the join with the Parent (which is a valid scenario - and BTW is what's happening now) Why don't you give it a try! On my case one of colleagues tried and I got another satisfied customer ;)

Transaction Management with JBoss Seam + JPA (Hibernate) like Spring Framework

I'm a fan of using Spring framework for all my projects, but unfortunately on my current project, I have to add a module to an existing app already developed using JBoss Seam EJB3 and Hibernate, so this is what I did to work with the same model of ServiceImpl that Spring uses

This is the DAO (Existing) - I just added the save method
@Name("purchaseDao") @AutoCreate @Stateless @TransactionAttribute(TransactionAttributeType.REQUIRED) @TransactionManagement(TransactionManagementType.CONTAINER) public class PurchaseDAO_EJB3_Impl implements PurchaseDAO { private static Log log = LogFactory.getLog(PurchaseDAO_EJB3_Impl.class); @PersistenceContext(type = PersistenceContextType.TRANSACTION) private EntityManager em; .... public void save(Purchase instance) { log.debug("Saving "+instance); em.persist(instance); log.debug("Saved"); } } And this will be My Service (I will not include the Interfaces)
@Name("enrollmentDetailsServiceBean") @AutoCreate public class EnrollmentDetailsServiceImpl implements IEnrollmentDetailsService { private static Logger log = Logger.getLogger(EnrollmentDetailsServiceImpl.class); @In("purchaseDao") private PurchaseDAO purchaseDAO; /* * Service method which will handle the Transaction */ @Transactional(TransactionPropagationType.REQUIRED) public Boolean saveEnrollmentDetails(EnrollmentDetails enrollmentDetails) throws Exception { Boolean result = false; try{ log.debug("Transform "+enrollmentDetails+" into POJOs"); Purchase purchase = Transformer.transform(enrollmentDetails); log.debug("Start saving PURCHASE, PURCHASE_MODULE & TRANSACTION"); purchaseDAO.save(purchase); log.warn("Insert another POJO (which already exists on the table) to break this thing :P"); Purchase purchase2 = new Purchase(); purchaseDAO.save(purchase2); log.debug("Inserts completed!"); result = true; }catch (Exception ex) { log.error("Error while saving EnrollmentDetails into DB: PURCHASE, PURCHASE_MODULE, TRANSACTION",ex); throw ex; } return result; } }
By doing this we have the same model of Tx Management - Just by adding the 1 annotation to the method!!! Cool Isn't it?
Also, in case that you want to make your Tx ReadOnly, just add this annotation to your method (also)

org.jboss.seam.annotations.ReadOnly

Unfortunately the documentation for JBoss Seam is really poor on this aspect, so If anybody finds anything that could be improved, please let me know)

OneToMany Mapping

I faced this issue on August, let me explain you the situation, I had a Table called PURCHASE, with a 1:N Relationship with PURCHASE_MODULE and TRANSACTION tables

TRANSACTION >-----PURCHASE-----< PURCHASE_MODULE

First thing, How do I represent that using annotations (Hibernate): @Entity @Table(name = "PURCHASE") public class Purchase implements java.io.Serializable { @Id @Column(name = "ID", unique = true, nullable = false, insertable = true, updatable = true, precision = 10, scale = 0) public long getId() { return this.id; } ... @OneToMany(mappedBy="purchase", fetch=FetchType.LAZY) public List<Transaction> getTransactions() { return transactions; } @OneToMany(mappedBy="purchase", fetch=FetchType.LAZY) public List<PurchaseModule> getPurchaseModules() { return purchaseModules; } } @Entity @Table(name = "PURCHASE_MODULE") public class PurchaseModule implements java.io.Serializable { @ManyToOne(optional=false, fetch = FetchType.EAGER) @JoinColumn(name="PURCHASE_ID", referencedColumnName="id") private Purchase purchase; } @Entity @Table(name = "TRANSACTION") public class Transaction implements Serializable { @ManyToOne(optional=false, fetch = FetchType.EAGER) @JoinColumn(name="purchase_id", referencedColumnName="id") private Purchase purchase; }
Now what I want is each time I populate Purchase and set both List's (transactions and purchaseModules) and Invoke a SAVE for Purchase, the 3 tables will be impacted( there will be at least 3 INSERTs): purchaseDAO.save(purchase)
But this wasn't working as I expected, because no matter if I populated both ArrayList's (List) I never saw more than 1 Insert on my console.

Then the spark I was looking for! Inspiration came to me :P
On the Annotation @OneToMany there is an additional attribute I didn't include: cascade (The operations that must be cascaded to the target of the association)
@OneToMany(mappedBy="purchase", fetch=FetchType.LAZY, cascade=CascadeType.ALL) public List<Transaction> getTransactions() { return transactions; } @OneToMany(mappedBy="purchase", fetch=FetchType.LAZY, cascade=CascadeType.ALL) public List<PurchaseModule> getPurchaseModules() { return purchaseModules; }
On my case I don't care, so I just include ALL operations :P

Primary key @OneToOne mapping in Hibernate (JPA)

My main objective is to save/insert as many POJO's as possible with the minimum # of calls to save method. That's why I'm relate them.

But there is a special relationship which it's not clearly documented on the official documentation, and that's why you'll see this entry here :)

.The problem is that I have 2 tables COURSE_ACCESS and COURSE_ACCESS_STATUS:

---------------
COURSE_ACCESS
---------------
*id
...
---------------

---------------------
COURSE_ACCESS_STATUS
---------------------
*course_access_id
...
---------------------

The relationship is 1:1. COURSE_ACCESS is the "parent" table, because that one has the SEQUENCE which generates the PK on "id" column.

Now what I want is when I save COURSE_ACCESS, COURSE_ACCESS_DATA should be saved too. Just like this CourseAccess courseAccess = Transformer.transform(user, enrollmentDetails, accessStartDate, new CourseAccess()); CourseAccessStatus courseAccessStatus = Transformer.transform(courseAccess, new CourseAccessStatus()); courseAccess.setCourseAccessStatus(courseAccessStatus);//Persisting CourseAccessStatus into CourseAccess this.courseAccessHomeService.save(courseAccess); //Instead of 2 DAO calls
How I did it?
@Entity @Table(name = "COURSE_ACCESS") public class CourseAccess implements Serializable { @Id @Column(name = "ID", unique = true, nullable = false, insertable = true, updatable = true, length = 40) @GeneratedValue(strategy=GenerationType.SEQUENCE, generator="courseAccessSequenceGenerator") @GenericGenerator(name = "courseAccessSequenceGenerator", strategy = "kaptest.util.domain.VarcharSequenceGenerator", parameters = {@Parameter(name = "sequence", value = "OI_SEQUENCE_NUMBER")}) private String id; … @OneToOne(cascade=CascadeType.ALL, fetch=FetchType.LAZY, targetEntity=CourseAccessStatus.class) @PrimaryKeyJoinColumn(name="ID", referencedColumnName="course_access_id") private CourseAccessStatus courseAccessStatus; }
@Entity @Table(name = "COURSE_ACCESS_STATUS") @org.hibernate.annotations.GenericGenerator(name="courseAccessFKGenerator",strategy="foreign", parameters=@org.hibernate.annotations.Parameter(name="property",value="courseAccess")) public class CourseAccessStatus implements java.io.Serializable { @Id @GeneratedValue(generator="courseAccessFKGenerator") @Column(name = "course_access_id", unique = true, nullable = false, length = 40) private String courseAccessId; … @OneToOne(cascade=CascadeType.ALL, fetch=FetchType.EAGER, targetEntity=CourseAccess.class) @PrimaryKeyJoinColumn(name="course_access_id", referencedColumnName="ID") private CourseAccess courseAccess; }

And that's it!!! Easy isn't it?

@Autowired and @Qualifier

"Your best friends could be @Autowired and @Qualifier"
I have to migrate data from DB2 to Oracle, both databases have the same structure, well, my Oracle has better design, but I'm reusing the some objects, like POJO's and DAO's, the only thing I changed were my mappings, because I have to keep my mappings for DB2 and for Oracle.
If I have the same DAO for both databases, what can I do?
daoApplicationContext.xml <?xml version="1.0" encoding="UTF-8" ?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jee="http://www.springframework.org/schema/jee" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-2.5.xsd"> <!-- ========================= Data Sources ============================= --> <bean id="db2DS" class="org.apache.tomcat.dbcp.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="COM.ibm.db2.jdbc.app.DB2Driver"/> <property name="url" value="jdbc:db2:best"/> <property name="username" value="${userId}"/> <property name="password" value="${pwd}"/> </bean> <bean id="oracleDS" class="org.apache.tomcat.dbcp.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/> <property name="url" value="jdbc:oracle:thin:@twsifcmtzdt01.tdc.vzwcorp.com:1535:mkssbxdb"/> <property name="username" value="${userId}"/> <property name="password" value="${pwd}"/> </bean> <!--============================= SessionFactory ===============================--> <bean id="sessionFactoryDB2" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean"> <property name="dataSource" ref="db2DS" /> <property name="configLocation"> <value>classpath:com/vzw/dvs/mapping/mappingDB2.cfg.xml</value> </property> <property name="hibernateProperties"> <props> <prop key="hibernate.dialect"> org.hibernate.dialect.DB2Dialect </prop> <prop key="hibernate.show_sql">false</prop> <prop key="hibernate.format_sql">true</prop> <prop key="hibernate.order_updates">true</prop> <prop key="hibernate.generate_statistics">true</prop> <prop key="hibernate.use_sql_comments">false</prop> <prop key="hibernate.bytecode.use_reflection_optimizer"> false </prop> <prop key="hibernate.jdbc.batch_size">15</prop> <prop key="hibernate.jdbc.batch_versioned_data"> true </prop> <prop key="hibernate.query.factory_class"> org.hibernate.hql.ast.ASTQueryTranslatorFactory </prop> <prop key="hibernate.connection.isolation">4</prop> </props> </property> </bean> <bean id="sessionFactoryOracle" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean"> <property name="dataSource" ref="oracleDS" /> <property name="configLocation"> <value>classpath:com/vzw/dvs/mapping/mappingOracle.cfg.xml</value> </property> <property name="hibernateProperties"> <props> <prop key="hibernate.dialect"> org.hibernate.dialect.Oracle10gDialect </prop> <prop key="hibernate.show_sql">false</prop> <prop key="hibernate.format_sql">true</prop> <prop key="hibernate.order_updates">true</prop> <prop key="hibernate.generate_statistics">true</prop> <prop key="hibernate.use_sql_comments">false</prop> <prop key="hibernate.bytecode.use_reflection_optimizer"> false </prop> <prop key="hibernate.jdbc.batch_size">15</prop> <prop key="hibernate.jdbc.batch_versioned_data"> true </prop> <prop key="hibernate.query.factory_class"> org.hibernate.hql.ast.ASTQueryTranslatorFactory </prop> <prop key="hibernate.connection.isolation">4</prop> </props> </property> </bean> <!-- ============================ DAOs DB2 ================================== --> <bean id="UserDAOdb2" class="com.vzw.dvs.core.persistence.dao.impl.UserDAOImpl"> <property name="sessionFactory" ref="sessionFactoryDB2" /> </bean> <!-- ============================ DAOs Oracle ================================== --> <bean id="UserDAO" class="com.vzw.dvs.core.persistence.dao.impl.UserDAOImpl"> <property name="sessionFactory" ref="sessionFactoryOracle" /> </bean> </beans>
As you can see, I have 2 different DAO's sharing the same Interface & Implementation, but each one belongs to a different "sessionFactory" <bean id="UserDAOdb2" class="com.vzw.dvs.core.persistence.dao.impl.UserDAOImpl"> <property name="sessionFactory" ref="sessionFactoryDB2" /> </bean> <bean id="UserDAO" class="com.vzw.dvs.core.persistence.dao.impl.UserDAOImpl"> <property name="sessionFactory" ref="sessionFactoryOracle" /> </bean> serviceApplicationContext.xml <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx" xmlns:util="http://www.springframework.org/schema/util" xmlns:context="http://www.springframework.org/schema/context" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd"> <!-- =============== JTA ==========================================--> <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager"> <property name="sessionFactory"> <ref bean="sessionFactoryOracle" /> </property> </bean> <!--====================== Transaction Managers with Annotations =====================--> <tx:annotation-driven transaction-manager="transactionManager" /> <!--====================== Enable Autowire =====================--> <context:annotation-config /> <!--================== Implementation of Services =====================--> <bean id="MigrateTablesService" class="com.vzw.dvs.core.business.service.web.impl.MigrateTablesServiceImpl"/> </beans>
Nothing special, right? But now here it comes the interesting part, because @Autowired by itself it will inject the given bean in your ServiceImpl, but you must have only one bean of that type. In my case I have more than 1, so @Autowired will throw an error when loading the context.
Then it comes @Qualifier which will match based on the given name, and problem solved chavos!!!
public class MigrateTablesServiceImpl implements MigrateTablesService { private static final Logger log = Logger.getLogger(MigrateTablesServiceImpl.class); @Autowired @Qualifier("UserDAOdb2") private UserDAO userDAOdb2; @Autowired @Qualifier("UserDAO") private UserDAO userDAO; @Transactional(readOnly = false, propagation = Propagation.REQUIRED) public boolean doMigrateUser() { log.debug("Migrating User"); boolean result = false; try{ List<User> listItems = this.userDAOdb2.getAll(); for(User transientInstance: listItems){ log.debug("Item retrieved from DB2 "+transientInstance); User user = new User(); BeanUtils.copyProperties(transientInstance, user); //Trim Strings user.setDbUserId(StringUtils.trim(transientInstance.getDbUserId())); user.setBudgetmanagerind(StringUtils.trim(transientInstance.getBudgetmanagerind())); user.setDashboardaccess(StringUtils.trim(transientInstance.getDashboardaccess())); user.setDirectorusercd(StringUtils.trim(transientInstance.getDirectorusercd())); user.setEmail(StringUtils.trim(transientInstance.getEmail())); user.setFirstname(StringUtils.trim(transientInstance.getFirstname())); user.setFunctionalareacd(StringUtils.trim(transientInstance.getFunctionalareacd())); user.setHomephone(StringUtils.trim(transientInstance.getHomephone())); user.setInternalit(StringUtils.trim(transientInstance.getInternalit())); user.setLastname(StringUtils.trim(transientInstance.getLastname())); user.setMobilephone(StringUtils.trim(transientInstance.getMobilephone())); user.setPassword(StringUtils.trim(transientInstance.getPassword())); user.setUserid(StringUtils.trim(transientInstance.getUserid())); user.setUserstatuscd(StringUtils.trim(transientInstance.getUserstatuscd())); user.setVpid(StringUtils.trim(transientInstance.getVpid())); user.setUtilizationtarget(StringUtils.trim(transientInstance.getUtilizationtarget())); user.setWorkphone(StringUtils.trim(transientInstance.getWorkphone())); if(user.getDbTimestamp()==null){ user.setDbTimestamp(new Date()); } this.userDAO.save(user); } result = true; }catch (Exception ex) { log.warn(ex); } log.debug("Done"); return result; }
Notes: I used org.springframework.beans.BeanUtils to create a copy of my bean (pojo) returned from DB2 into a non-persistent Pojo which I'll manipulate before inserting into Oracle (DB2 completes each column value with spaces to achieve the given size of that column, so each time you query a DB2 column you'll get a lot of extra spaces)

EmbeddedId in Hibernate, AnnotatedClasses

I had to do some inserts to a table with a composite PK:



Nothing special, I decided to use Hibernate with annotations (but what about the PK: just create another class -duh, but How can I tell hibernate this is my PK? @EmbeddedId and @Embeddable):

@Embeddable

Defines my composite PK @Embeddable public class RimMessageId implements Serializable { private static final long serialVersionUID = -1L;//Just 4 fun ;) @Column(name = "dvs_server", length = 10, nullable = false) private String server; @Column(name = "dvs_yyyy", length = 4, nullable = false) private String year; @Column(name = "dvs_month", length = 2, nullable = false) private String month; @Column(name = "dvs_dd", length = 2, nullable = false) private String day; @Column(name = "dvs_hh", length = 2, nullable = false) private String hour; @Column(name = "dvs_mm", length = 2, nullable = false) private String minute; @Column(name = "dvs_ss", length = 2, nullable = false) private String second; @Column(name = "dvs_millis", length = 6, nullable = false) private String millis; //Gette's and Setter's }

@EmbeddedId

Includes my composite Pk in my main Pojo @Entity @Table(name = "RIM_MESSAGES") public class RimMessage implements Serializable { private static final long serialVersionUID = 1L;;//Just 4 fun ;) @EmbeddedId private RimMessageId id; @Column(name = "mdn", length = 10) private String mdn; @Column(name = "bun", length = 20) private String bun; @Column(name = "evt", length = 6) private String evt; @Column(name = "bsh", length = 2) private String bsh; @Column(name = "bex", length = 10) private String bex; @Column(name = "lng", length = 3) private String lng; @Column(name = "rim_tod", length = 4) private String rimTod; @Column(name = "rim_doy", length = 8) private String rimDoy; @Column(name = "rim_ip", length = 15) private String rimIp; //Gette's and Setter's }
If you want to include in your sessionFactory (daoApplicationContext.xml) my annotated pojos, add this entry <property name="annotatedClasses"> <list> <value>com.vzw.gsb.core.persistence.integration.RimMessage</value> </list> </property>
As a reminder, if you want to use a propeties file to provide parameter for your DataSource, you have to do this: <!-- ========================= Properties ============================= --> <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> <property name="location"> <value>classpath:rim-rtr-messages.properties</value> </property> </bean> <!-- ========================= Data Sources ============================= --> <bean id="myDataSource" class="org.apache.tomcat.dbcp.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="${driverClassName}"/> <property name="url" value="${url}"/> <property name="username" value="${username}"/> <property name="password" value="${password}"/> </bean>

Annotation-Based Transactions

Spring provides several different approaches to transaction management:

• Programmatic: You can write your transactions using Java source code directly. Normally you wouldn't do this unless you needed fine-grained control over some particular transaction.
• Declarative: You can declare transaction definitions in either a centralized way using XML or in a distributed way using annotations:
  • XML-based: You can configure transactions in Spring's centralized application context file. Once again you have options:
    • Proxy-based: In this approach you wrap your service beans with transactional proxies. The proxy and the service bean both implement the same Java interface so the application can't tell them apart. This is a fairly verbose approach with respect to the actual context configuration though there are techniques you can use to streamline the configuration.
    • AOP-based: Here you define AOP aspects to endow your service beans with transactional semantics. Not quite as verbose as the proxy-based approach.
  • Annotation-based: You can use Java 5 annotations to distribute transaction configuration across Java classes.

With Spring, you typically apply transaction annotations either to Java interfaces for service beans, or else to the service beans themselves. If you apply the annotations to the interfaces then the transaction definition holds true for any classes implementing those interfaces. We'll do that here, but remember that you can apply the annotations to the service beans themselves as well.
Here's an interface for a simple article service. This service allows the application to get an article by ID, and also to post a comment for a given article. package mx.com.myapp.business.service; import org.springframework.transaction.annotation.Isolation; import org.springframework.transaction.annotation.Propagation; import org.springframework.transaction.annotation.Transactional; import mx.com.myapp.persistence.domain.Article; import mx.com.myapp.persistence.domain.Comment; @Transactional( propagation = Propagation.REQUIRED, isolation = Isolation.DEFAULT, readOnly = true) public interface ArticleService { Article getArticle(long articleId); @Transactional(readOnly = false) void postComment(long articleId, Comment comment); }
The first thing to notice is again just how ridiculously simple this is. I probably don't need to explain it but I will anyway just to be safe. The @Transactional annotation we define on the interface is setting default values for the various methods that form the interface. So we are saying here that unless the method itself specifies otherwise, we want Propagation.REQUIRED for the propagation behavior, we want the default isolation level, and we want to flag methods as read-only.
The only other piece to mention is that I've overridden the readOnly setting for the postComment method since that's obviously a write method.
If it could be any simpler I'm not sure how. Now let's look at the Spring configuration file.

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd"> <!-- Wire beans here --> ... <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager"> ... </bean> <!-- This tells Spring to activate annotation-driven transactions --> <tx:annotation-driven/> </beans> That's it—really! Make sure you include both the aop and tx namespaces and schema locations since that's where the magic lives. You have to wire your beans up just like you normally would. And you have to provide a transaction manager of one kind or another. I'm using the Hibernate 3 HibernateTransactionManager but use whatever you want. If you give your transaction manager the id transactionManager, then you can take advantage of a little Spring convention-over-configuration: <tx:annotation-driven> will pick that up automatically. (And if you want to call your transaction manager something else, that's fine too. Just reference that ID using the transaction-manager attribute of the <tx:annotation-driven> element.)
Oh, the <tx:annotation-driven> element just tells Spring that you want it to pick the transaction definitions up from the Java annotations. I'm not sure how it works behind the scenes, but I think Spring will run through the beans in your context and create the necessary transaction aspects. Not positive about that—if you know the details, I'm interested—but in any case you end up with annotation-driven transactions. Nice!

Annotation-Based Autowiring in Spring 2.5

Add annotations to name your DAO, service and controller classes
Chances are good that your DAO and service classes don't have the names that name-based autowiring would require. For example, you might define interfaces that have the "right" names, such as a CategoryDao interface, or a ProductService interface, and then your concrete implementation classes would be HibernateCategoryDao or ProductServiceImpl (or whatever), which won't autowire to the desired properties unless you have some strange and ill-advised property names. So our first order of business is to provide the requisite names. With manual wiring, you provide this on the <bean> element using the id or name attributes. But we're trying to eliminate said elements from our config, so that option is unavailable. We use annotations instead.

For each DAO, add a class-level @Repository annotation. These annotations go on the implementation class, not on the interface. import org.springframework.stereotype.Repository; @Repository("productDao") public final class ProductDaoImpl extends AbstractHibernateDao implements ProductDao { ... }
The @Repository annotation works in Spring 2.0 as well.

For each service component, add a class-level @Service annotation. As before, these go on the implementation class, not on the interface.
import org.springframework.stereotype.Service; @Service("productService") public final class ProductServiceImpl implements ProductService { ... }
Note that @Service is new with Spring 2.5. So it won't work if you're using Spring 2.0 or earlier.

For each Spring MVC controller, add a class-level @Controller annotation.
Don't worry about providing a name; we won't need it. (So this step is a little out of place in these instructions, but go ahead and do it anyway as you will need the @Controller annotation if you want to fully autowire the web tier.) Just do this for each controller:
import org.springframework.stereotype.Controller; @Controller public final class ProductController { ... }
Like the @Service annotation, @Controller is new with Spring 2.5.
At this point we've haven't really changed anything; you still have names defined in the manual configurations in addition to the annotation-based names you've just added. Test out your app to make sure we haven't broken anything, and then move on to the next step.

We have to tell Spring two things: where to find the names, and what strategy to use (viz., autowiring by name) for autowiring.

Tell Spring where to find the annotation-based names
You will need to use the <context:component-scan> element to do this. Since it's in the context namespace, you must declare that namespace and schema location in your Spring config files. Here are examples from the data access, service, and web configurations: lt;!-- Spring configuration for data access tier --> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd" default-autowire="byName"> <context:component-scan base-package="x.y.dao"> <context:include-filter type="annotation" expression="org.springframework.stereotype.Repository"/> </context:component-scan> ... </beans> <!-- Spring configuration for service tier --> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd" default-autowire="byName"> <context:component-scan base-package="x.y.service"> <context:include-filter type="annotation" expression="org.springframework.stereotype.Service"/> </context:component-scan> ... </beans> <!-- Spring configuration for web tier --> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd" default-autowire="byName"> <context:component-scan base-package="x.y.web"> <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/> </context:component-scan> ... </beans>
In the above, the pieces relevant to component names are the xmlns:context declaration, the xsi:schemaLocation declaration, and the <context:component-scan> configuration. I'm telling Spring to scan the x.y.dao package for components that have the @Repository annotation, to scan the x.y.service package for components that have the @Service annotation, and to scan x.y.web for components that have the @Controller annotation. Spring will do that, and in the case of the data access and service components, it will use the value we provided to the annotations in step 1 above as a basis for name-based autowiring. (We didn't provide any names with the @Controller annotation though I would assume you can do that. It happens that in our case we won't need it.)
You'll notice however that I've snuck in some default-autowire="byName" attributes in there. As you can guess, that's for autowiring, and we'll look at that in just a second.

Make sure you have public setters for each bean that you want autowired
It appears that default-autowire="byName" autowiring is based on public setters. (With the @Autowired attribute applied to fields you can avoid the setters, but if you have unit tests, you'll need setters to inject mocks, and so you may as well just keep the setters and make them public. Weaker visibility doesn't appear to work)

Tell Spring that you want to use name-based autowiring
The default-autowire="byName" attribute tells Spring that you want to use component names to automatically wire up the app. In step 1 above we went through the process of providing correct names ("correct" here means names that match the injection property names) for DAO and service classes. That will allow us to remove the DAO and service components from our Spring config. In all likelihood there will be other components that you can't remove from the config, such as a Hibernate SessionFactory in your data access configuration or a TransactionManager in your services configuration. In cases like that, just make sure that the names (or IDs) that you give to the components are the ones that would be expected when doing name-based injection. Here are some examples: <!-- Hibernate session factory --> <bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean"> ... </bean> <!-- Hibernate transaction manager --> <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager"> <property name="sessionFactory" ref="sessionFactory"/> </bean>
Note that using default-autowire="byName" allows you to avoid having to use the @Autowired attribute on your various dependency injection fields or setters. You shouldn't have to use that at all if you follow these instructions.
At this point you should be able to remove the following configurations:

• The DAO component definitions from your Spring data access configuration file (but don't remove the SessionFactory).
• The service component definitions from your Spring service configuration file (but don't remove the TransactionManager).
• The service injections from your MVC controllers in your web configuration file. Don't remove the controllers themselves for now; you still need those for defining URL mappings. Just remove the service injections since those will now be autowired. (Note that there's a way to eliminate the MVC controller configurations as well
• The sessionFactory injection from your TransactionManager definition since that will be autowired, the dataSource injection from your SessionFactory (assuming you have an appropriate ID on the DataSource config), etc. In general just look through your configs for elements that will now be autowired and either comment them out or remove them.

I would recommend commenting things out first and then testing the app to make sure it still works.