Featured White Papers

• What Developers Want: The End of Application Redeploys

Sponsored Links

• Career opportunities at Harman- Careers That’ll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Build an object database, Part 2: Object storage backend

Implement relational database storage for Java objects

By Michael Shoffner and Merlin Hughes, JavaWorld.com, 04/07/00

Tools do exist to help with this process, usually at a "generous fee" (with respects to the late Curtis Mayfield). Sometimes the tools are necessary, especially when mapping from an existing relational data model to an object model. However, when the relational model is not set in stone, it is possible to let the object model drive the relational model, allowing storage options to surface closer to home.

TEXTBOX:

TEXTBOX_HEAD: Build an object database: Read the whole series!

• Part 1: Construct a frontend to translate between Java objects and relational database records
• Part 2: Implement relational database storage for Java objects

:END_TEXTBOX

The most obvious solution: serialize each Java object using the object streams and slap the result into a database as a binary blob. While this is certainly a valid option and the JDBC explicitly supports it, blobs cannot be readily manipulated (or even read) by anything other than other Java applications. So interoperability, along with human readability, go out the door.

The relational storage backend we'll build alleviates this data- interoperability problem. Our backend actually creates relational tables for each class and maps each instance's variables into them as columns, creating a sort of poor man's object-relational mapping, if you will. (To download this article's complete source code, go to Resources.)

Framework overview revisited

The object-storing framework introduced in the January Java Step by Step time divides the work of persisting Java objects into two tasks:

1. Frontend: Scatter the object into its fields, preserving its type information -- the responsibility of an ObjectStorer implementation.
   
   
2. Backend: Store the values of the fields along with type information -- the responsibility of an ObjectStorage implementation.

Figure 1. The object storage architecture

The object-storing framework enables object storers and object storage implementations to vary independently. The object storer doesn't care how the object storage implements its storage behavior, and the object storage doesn't know that the object storer exists. This is as it should be.

The ObjectStorer interfaces look like this:

 public interface ObjectStorer {
  public void put (Object key, Object object) throws IOException;
  public Object get (Object key) throws IOException,
                                        ClassNotFoundException, 
                                        IllegalAccessException, 
                                        InstantiationException;
}

In the January Java Step by Step, Merlin provides implementations of this interface -- most notably a SerializationStorer.

In this article, we'll complete the framework by implementing the ObjectStorage interface, as seen below:

 public interface ObjectStorage {
  public void put (Object key, StorageFields object) throws IOException;
  public RetrievalFields get (Object key) throws IOException;
  } 

The ObjectStorage interface uses the StorageFields and the RetrievalFields classes to pass information about fields that are stored and retrieved, as we'll see next.