On Java Development

All things related to Java development, from the perspective of a caveman.

Archive for August, 2014

Parsing XML Data Elements Using Apache Digester

without comments


This post presents Apache’s Digester project which implements the SAX API. While Digester is not as fast as alternatives, it is faster than DOM based parses and consumes less memory. Digester is very flexible and data elements can be mapped to any data object e.g. ArrayLists, Maps, Entities, etc.

Presented are a couple of examples showing how Digester can be used to isolate data to be persisted as entities in a database.
Read the rest of this entry »

Written by admin

August 15th, 2014 at 11:56 am

Posted in XML

Hibernate’s Transparent and Automated Persistence

without comments


This post highlights aspects of Hibernate’s record update strategy called “Transparent and automated persistence”


Persistent Object States

Hibernate defines four object states: transient, persistent, detached, and removed. The following sections presents details on each state and the methods in Hibernate or JPA that can move an object to that state.


Transient Objects

Objects instantiated using the new operator are called transient objects. The Hibernate persistence context isn’t aware of operations performed on transient objects. Their state is lost when they aren’t referenced by any other object and become available for garbage collection. They don’t have any association with any database table row. JPA doesn’t have this state. The figure below shows the creation of a transient object.


Persistent Objects

An object that has a database identity associated with it is called a persistent object. The key for an object to be in a persistent state is to be associated with a persistent context. The persistent context caches the object state and can identify changes made, if any. You can create persistent objects two ways: you can retrieve a database table row as an entity by calling API methods like get(), load(), and list(); or you can persist a transient object using API methods like save() and saveOrUpdate(). The figure below shows the possible ways for an object to become persistent.


Detached Objects

A persistent object is associated with a persistent context. The persistent context no longer exists after the transaction is closed. If the application retains a reference to the persistent object, then the object is said to be in the detached state. The state of a detached object can be modified and can be persisted back to the database. This is very common when you’re working with applications that have a multilayered architecture. The figure below shows how an object can become detached. Hibernate provides a reattached mode and a merging mode to make a detached object persistent. JPA has merging mode only.


Removed Objects

A persistent object is considered to be in the removed state when a delete() or remove() operation is called on it. The delete() method is provided by a Hibernate session, whereas the remove() method is provided by the JPA EntityManager. Note that when an object is removed, the persistence context then deletes the object from the database. This means you shouldn’t use any references to the removed object in the application. The figure below shows how this state can be obtained.


Transparent and Automated Persistence

Entity classes represent physical records in the database. When using an entity manager, which essentially describes Hibernate, entity objects are being managed through different phases of its life-cycle. The following diagram illustrates the life-cycle of an entity with respect to Hibernate’s API.

If a managed entity object is modified within an active transaction the change is detected by the owning EntityManager and the update is propagated to the database on transaction commit.

For example, the following code retrieves an entity from the database and increments its field value. The change of the value occurrs on line 16. This causes the EntityManager to persist the record when the transaction is committed, which occurs in the Service Layer of the application.

Transparent persistence fosters a degree of portability; without special interfaces, the persistent classes are decoupled from any particular persistence solution. Business logic is fully reusable in any other application context. You could easily change to another transparent persistence mechanism. Because JPA follows the same basic principles, there is no difference between Hibernate persistent classes and JPA entity classes. – Java Persistence with Hibernate

Anyone who has written a PHP application will appreciate the above. Using PHP, the application is hard-wired to the underlying database. For example, the connection and CRUD operations differ across the spectrum of vendor databases providing zero possibility for portability without rewriting the DAO layer. Contrasting this against a Java application using Hibernate, the application can operate without modifications to the persistence layer whether it is using a MS-SQL Server, Oracle. DB2 or DB/400.

Written by admin

August 1st, 2014 at 5:47 am

Posted in Hibernate