Monday, May 12, 2008

Should I use JPA in my Business Application?

Why I love JPA is because it promises to relieve and Architect from making early decision for choosing a persistence engine। A development team can start the development with most common persistence engine। Since the application uses standard JPA, the application Architect can take time to evaluate and identify the best persistence engine for the application.

Well! Does JPA 1.0 live to its promise? Not really. I learned it the hard way. There are many features which are crucial in building an enterprise application but are missing from JPA 1.0. However these features are already implemented by all major persistence engines. Some of these missing features are :


  1. JPA does not support deleting orphaned children. For example, I have two persistence entities; Order and LineItem. The relation from Order to LineItem is composition. An Order can contain many LineItems. LineItem entity's life is bound to an Order. It can not live on its own. Well now user creates an order, adds a line item to the order and saves it. User then deletes old line item from then order and adds a new line item and re-saves the order. Now what happens during second save is that JPA instructs underlying engine to delete the association between first line and order however the line item itself is never deleted. It's order id will be null. If you put constraint in the database that order_id in lineitem table can not be null, the second save operation will fail with database constraint exception. Well hibernate has an additional annotation @CascadeType.DELETE_ORPHAN' to delete such orphan children. TopLink has similar extension. I don't know how did JPA spec team missed such an important feature.
  2. JPA 1.0 has lack of custom datatype mapping to database. Support for Boolean is weak in JPA. I know Database savvy people (especially oracle savvy) like to represent boolean flag with single character column with possible values of 'Y', 'N' or null however, Java people like to represent it with and attribute of type Boolean. How do we fill the gap? Well hibernate allows one to specify different type of mapping for boolean. You can choose datatype as yes_no. However JPA 1.0 does not have any equivalent.
  3. JPA supports JPQL which is a huge step forward from old EJBQL. However, since JPA does not have support for Criteria API (similar to the one in Hibernate), developers are left to deal with the mess of String manipulation for building dynamic JPQL for the given dynamic search criteria. Dynamic search criteria isn't uncommon for any enterprise application. In small application, you might see very messy code that does criteria comparison and string manipulation. Or for big projects, you will see a home-grown solution that is similar to Hibernate Criteria API.
  4. This list can go on and on such as missing support for primitive array. However, I think I made the point.

Now in order to fill the gap, we have three options:


  1. We can write the application code to fill the missing gaps.
  2. We can write home grown abstraction layer that hides the internal details of vendor specific extensions.
  3. Or we can commit ourselves to a specific persistence engine and use it's extended features.

I think everybody will agree with me that option 1 should be out unless you know what you are doing (special defense project, need extremely high performance system, manager got too much money to spend)

If I am standard savvy, Sun Microsystem's employee or working for a large project, I will choose the second option as it still leaves the door open for using different persistence engine in future.

Well, I am though standard savvy. But over many years I learned that a business does not give a “****” to the standards. All it cares about is a solution that can be developed within budget by given developers and will be able to keep their business running. So for small to medium size projects, I will recommend on using a concrete persistence engine. Believe me, it will save you lot of time and energy during the design and development.

I hope that I don't have to stick with my decision for long time. I have seen the JPA 2.0 specification which seems to address many issues with JPA 1.0. I hope with the release of JPA 2.0, we should be able to use standard based persistence solution in the application.

No comments: