To JPA or not - an introspection on the Java Persistence API

One fine day I was looking into the object persistence architecture we utilize in my project. We use a simple Hibernate based persistence, connecting to our database through JDBC, using JDBC’s transaction semantics. Then i came to thinking is there any advantage of using JPA over Hibernate as opposed to plain old Hibernate. Here are some of my thoughts. Let me start off by talking about persistence, hibernate and JPA in general.

What is persistence?

The general idea behind persistence is to extend an object’s life span. There are technically many ways to implement this. A simple way is to simply store the object as a file on the disk and then convert it back into an object, a good example of this is persisting objects as XML. Another alternative is using a database to store the data. The decision on which kind of persistence to implement basically depends on the kind of functionality that you need to implement. In my project we use both database based persistence and file based persistence (we use XStream , which is again a story for another day)

Let us consider persistence with a database perspective. Traditionally databases follow a relational paradigm. A Table is the main actor and is related to other tables through a relation. But an Object on the other hand compromises an entity along with methods that operate on the entity and it’s association with other entities. This has led to an object relation impedance mismatch which makes it tough to convert between those two.
Say hello to Hibernate and JPA!!

Hibernate has filled this void albeit not perfectly but enough to do the job. Persistence frameworks
is the key behind object relational mapping. Hibernate so far used to do persistence with it’s own Core API. EJB 2.1 was on the wane, a bloated technology, losing it’s grandeur, then came the redesign and scripting of a new reign of a new technology, EJB 3.0 specification that provided the JPA specification as it;’s answer to the entity beans of old.  Hibernate 3.0 has to adapt to this changing world and adopted the JPA specs as it’s own.

JPA essentially provides a POJO based persistence model. It replaced entity beans which had the following problems:
- too heavyweight and coupled to the application server itself
- difficulty in deploying and unit testing

JPA essentially provides a standardization to the persistence methodology. Thus allowing any persistence framework to be used underneath JPA without having to worry about too much configuration. Hibernate implements the JPA specification by creating a wrapper over the Hibernate Core. This wrapper can be further made more effective by introducing annotations to take out some of the responsibility of the configuration file.

When thinking about the JPA specs, we introduce Hibernate EntityManager which is used to define the JPA life cycle rules for persistent objects, and is used as a wrapper around HibernateCore. The advantage of using JPA is that it brings with it some portability when having to switch between application servers that support JPA, which may not be possible with a Hibernate based solution.

JPA has many components that can be somewhat mapped to Hibernate:
EntityManagerFactory –> SessionFactory,
Persistence class creates the EntityManagerFactory,
EntityManager –> Session,
Query –> Query,
EntityTransaction –>Transaction.

It only needs a persistence.xml in the  classpath which configures basic hibernate connection properties.
Everything else is managed through Annotations (for ex. a PersistenceContext injects a EntityManager object into the bean).

The advantage of using Hibernate with JPA is that you can enabled several features of Hibernate without having to mess with the  JPA configuration like for example a second level hibernate cache. In addition to this you can use native hibernate mapping and API,  the only problem with this is that if you decide to use a different JPA provider, it’s gonna get dirty.

Ex 1: If you want to export the schema programmatically, then use a Hibernate Ejb3Configuration()
that can easily replace the EntityManagerFactory, which can yield a AnnotationConfiguration that can
be passed into the SchemaExport instance.

Ex 2: Use the SessionFactory if you need programmatic control over the
second level caching. This can be done by fist casting EntityManagerFactory into
HibernateEntityManagerFactory and then extracting the SessionFactory.

But using JPA also has some disadvantages
* no control over cascading behaviour
* no indexed collections,
* Hibernate provides Filters and Caches
* no collections of primitive values

How useful would JPA be for me in my project?

This is an interesting question. One reason for the shift to JPA could be the standardization aspect, with increased portability. Now we no longer need to worry about moving to a different persistence provider like Hibernate or JDOLink, a concept called pluggable persistence providers. Now the question do I need it for my work? Is it worth sacrificing some of the features of hibernate like cascading and indexed collections for a standardized interface. For now i dont think so, but in the future if we decide to move to a full fledged application server like JBoss, most likely.

Some reference links for this particle post

http://asrijaffar.blogspot.com/2007/01/native-hibernate-vs-hibernate-jpa.html
http://maestro-lab.blogspot.com/2007/09/coding-java-persistence-jpa-vs.html
http://www.javaworld.com/javaworld/jw-07-2008/jw-07-orm-comparison.html
http://clarkupdike.blogspot.com/2007/01/hibernate-mappedby-to-superclass.html

Tags: jpa, persistence

improving performance in hibernate

For the last few months I have been looking at performance improvements for my application on multiple ends. One is at the GIS end and the other is of course the database end. Caching  is a great way to provide the performance improvement. Caching on the GIS end was an interesting exercise I implemented, which is a story for another day.

Today let me pen my thoughts on improving performance at the Hibernate level. Hibernate has many performance improvement techniques, of course we have implemented a small sub set of that for our task. Let me first talk about Hibernate’s performance improvement strategies. If you want to take it all in at a glance, take a look at this mind map image (maybe click on it to enlarge it)

First we need to understand that

• Sessionfactory is an immutable thread safe factory that initalize JDBC connections, connection pools and create Sessions.
• Session is a non thread safe single unit of work that represents a transaction

Caching, a blessing in disguise

Caching reduces traffic between the database and application by conserving data that has already been loaded into the application. Caches store data that was already fetched so that multiple accesses on the same data takes lesser time. Essentially caching reduces disk access, reduces computation time and speeds up response to users.

Hibernate uses three levels of caching.

• Level 1 mainly caches at the Session level
• Level 2 cache does it as the SessionFactory level.
• Query cache

Hibernate uses Level 1 cache to mainly reduce the number of SQL queries. It is always the default cache. If there are several modification on the same object it will simply generate a single SQL query for this. The level 1 cache is usually restrained to be for a single session, it is short lived. Essentially the general idea behind the fist level cache is that it batches queries.

A Level 2 cache is designed to interoperate between sessions. Level 2 cache is usually recommended when we are dealing with read only objects. It is not enabled by default. It is conceptually a map that has the id of the object as the key and the set of attributes the entity has as the value.

The Query cache is not on by default either. It uses two cache regions -

• StandardQueryCache - stores the query along with the parameters as key to the cache region. So any subsequent queries with the same key will hit the query cache and retrieve  the object from the cache
• UpdateTimeStampsCache - tracks the timestamps of the most recent updates to particular tables to identify stale results

Remember all this caching will only be effective in reducing the number of queries if we use session.get to load the object. Using HQL to load the object may in fact create more queries.

Hibernate has four basic types of cache providers-

• EHCache - fast, lightweight, read-only and read write caching support,memory and disk based caching , no clustering.
• OSCache - read only and read write caching, memory and disk based caching, clustering support via JMS or JavaGroups.
• SwarmCache - cluster based caching based on JavaGroups, read only and nonstrict read write caching, usually used when there are more read operations than write.
• JBoss TreeCache - replicated and transactional cache.
• Tangosol Coherence Cache

The caching strategy is specified using a <cache usage = “”> tag. The caching strategies maybe:

• read only - for frequently read data, simple, best performer.
• read-write - data needs to be updated, never used if serializable transaction isolation level is needed, need to specify a manager_lookup_class in JTA environment.
• nonstrict read-write - rarely updating data , need to specify a manager_lookup_class in JTA environment.
• transactional - only used in a JTA environment

If the hibernate.cache.provider_class property is set, second level cache is enabled. Cache can be configured within hibernate.cfg.xml. Cache’s usage patterns can be defined within the <cache> element in the hbm’s associated with each domain class. Enable query caching by setting hibernate.cache.use_query_cache to true and call the setCacheable(true) on the Query object. Query cache always uses the second level cache. The Cache is loaded whenever an object is passed to save(), update(), saveOrUpdate() or when retrieving objects using load(), get(), list(). Invoking flush() will synchronize the object with the database. Use evict() to remove it from cache. A CacheMode defines how a particular session interacts with second level cache -

NORMAL - read and write to cache,
GET - read but dont put,
PUT - write but dont read,
REFRESH - force refresh of cache for all items read fromt he database

Fetching strategies

A fetching strategy identifies how hibernate will fetch an object along with it’s associations once a query is executed. There are four types of strategies

• Join Fetching - All associated instances are retrieved in the same SELECT using OUTER JOIN. But having too many of this can result in a huge chunk of the database coming into memory, cause performance hurdles there.
• Select Fetching - This is the default strategy. A second SELECT retrieves associated entity or collection. This is usually lazy unless specified otherwise. This is extremely vulnerable to the N+1 select problem, so instead the join fetching can be enabled.
• Subselect fetching - similar to select but retrieves associated collections for all entries fetched previously.
• Batch fetching - optimization on select fetching where a batch of entities are retrieved in one select

As far as we are concerned, we pretty much use EHCache as our caching strategy and do a lot of join fetching / lazy select fetching based on our requirements.

Of course all these technical ideas are borrowed from these websites

http://acupof.blogspot.com/2008/01/background-hibernate-comes-with-three.html
http://www.devx.com/dbzone/Article/29685
http://www.hibernate.org/hib_docs/reference/en/html/

Tags: hibernate, java, performance

web application state

Just the other day i started thinking about application state in our web application. HTTP is essentially a stateless protocol, which basically means that every request between the client and server is essentially a self contained unit with all the information required for each transactions embedded within the request.

Consider the figure above, that represents a typical Http model. Every HttpRequest will encode the information in the HttpRequest header and sends it over to the server which does processing and returns the response back as HTML.

But then there is more to Http than meets the eye. Http has been extended to allow state information to be stored. How many times has the word “session” been thrown around. What exactly is this session?

The HTTP model has three major scoped containers - HttpRequest, HttpSession and ServletContext. We will look at ServletContext some other time. HttpRequest of course works on a per request basis. All variables will have scope only for the lifetime of the request. HttpSession is a container where the scope of variable is essentially global. But how does this HttpSession work? The magic behind HttpSession is a concept called cookies and URL rewriting (if cookies are disabled).

Esentially there are three major ways to maintain the state between multiple stateless protocol requests.

• cookies - store state information client side, and send that state to server everytime a request is made
• hidden form fields - store data hidden in forms and send the form everytime a request is sent to the server
• URL rewriting - encode the state information within the URL. This is usually done using a jsessionid name value pair appended to the URL by the server at the end of each request.

Essentially once a cookie is created with session information, it is stored at the client, for future requests to look it up and regain the state. Alternatively using hidden form fields, the state itself can be transferred from one request to another. Last but not the least, URL rewriting can also do the trick.

Maintaining state is done by the servlet container like Tomcat. Tomcat maintains HttpSession either using client side cookies, or if cookies are disabled through URL rewriting.

Tags: application state, java

how i used Spring at ma’ workplace - Part 1 - Soft Introduction

I’ve been relearning some of the base technologies we use in our project ( there are a lot fo them) but the most interesting one is Spring. I am sure all of u know what Spring is and how it works. Let me just talk about one interesting aspect of spring that we actually use in our project - dependency injection or in technical terms, the Spring IOC Container.

let’s talk about Inversion of Control first. It’s very popularly known as the “Hollywood principle” because of it’s underlying concept which is “you dont call me, I’ll call you“. These are the important principles behind the Hollywood Principle

• loose coupling - imagine a slice of bread. A slice of bread is loosely coupled because in itself, it is just bread. People buy bread as it is. But then the coolness is when bread gets converted to a vegetable sandwich or bread becomes bread omelet sandwich. That, my dear watson, is called loose coupling. There is a very minimal assumption about the interface of bread. If you decide to make a wheat bread instead of white bread, you can still make a vegetable sandwich or a bread omelet sandwich. Similarly we write a Java object that is independent by itself and has no dependencies. It is exposed through an interface. Any changes in the object will not have an effect on the classes that use this object.
• sacrifice of control - let the restaurant chef decide what to put in the bread rather than letting the bread maker dictates terms as to what should a bread contain. Similarly we let the system define how it wants to use the object and what it wants to add to the object.

So Inversion of Control is a broad term that encompasses the Hollywood Principle. It is a general principle of most frameworks. Simply stated the framework takes the responsibility of invoking a module’s functionality away fromt he module and puts it in the controlling framework itself. There are many different example of IOC in action. EJBs, JUnit uses IOC , dependency injection in Spring, etc.

What is the difference between Inversion of Control and Dependency Injection?

How about you wait for ma next post ??

References:

1. http://martinfowler.com/bliki/InversionOfControl.html
2. http://en.wikipedia.org/wiki/Inversion_of_control

Tags: dependecy injection, inversion of control, spring

Does java passes by value or reference?

So the other day someone asked me

“Does Java pass by reference or by value?”

Hey I answered, I ought to know this,

“By value of course.”

So imagine an object Person P passed into a function doModifyPerson(Person p). I call P’s setter, say p.setName(”initalName”) and i then invoke p.setName(”new Name”) inside the function doModifyPerson.

Now the question is does Person p get modified?

So i answered,

“No way jose, Java is pass by value aint it”

Guess what amigos!!…I was dead wrong. Java is pass by value, of course, but in this case the Person object’s reference is passed by value, not the value itsef. So we have two references pointing to the same Person object, so u modify the reference’s value of course the object’s value changes.

But then why does this not happen with Strings, Strings are objects too, but they dont get modified inside the function. Guess what Strings are immutable.

So another instance of not getting my concepts right.

Tags: java