Building the Application
Now that we've got everything we need, let's get down to business. This section will walk you through the key aspects of building an OODB-enabled application. I am presuming that you already have set up J2SE, Xerces-J, ObjectStore PSE, and the various settings of the environment. You can use links to the full code at the end of the article.

Commence Coding
One of the major benefits of many OODB solutions is the ability to start coding the application without immediate integration or prior knowledge of the OODB itself. OODB implementations vary, but many allow classes to exist in the data layer without being aware of the OODB technology behind the scenes.

In order to show the evolution of the application from pure Java to an OODB-enabled Java application, I developed the code in two phases: database-independent and OODB-enabled. In the pre-OODB code, I simply implemented the design shown in Figure 1. The functionality was fairly simple: the addition of single entries or batch uploads of phone book entries from an XML file. The following code shows the execution of the application:

0: Quit,  1: Add,  2: Upload
Choice: 2
Enter new batch phone list...
XML File Name [batchEntries.xml]: batchEntries.xml
  Added 555-123-4567: Bean, Ed    13 No Where 
Street (apt. 2a) [...]
  Added 555-555-1212: Doe, John   1 No Such 
Street [...]

Without a persistence or serialization solution, added entries would be lost as soon as the program terminated. This application needs some form of persistence to go to the next step.

Setting Up the OODB
By simply adding an OODB, the functionality of this application was enhanced. At the very least, an OODB version should support basic query, delete, update, and improved reporting functionality.

I first had to decide where the OODB interface would reside. I didn't have to modify all data classes to know about the OODB, since an OODB simply stores objects when asked. However, some code had to tell the OODB which objects to store, retrieve, modify, etc. Looking at the design, the Phonebook class appeared to be the most likely candidate to enhance, given its container-like behavior. Whereas the first version of Phonebook.java relied on a stack for storage (a map probably would have been a better choice), the new version tied into the ObjectStore OODB for storage.

Other than setup, which takes place in the code, no database installation or setup is necessary. Unlike most relational databases, creation of the database in this demo is done on the fly. Let's look at the basics of an ObjectStore-enabled Phonebook class.

Code: Phonebook Import Statements
  
import com.odi.*;
import com.odi.util.*;
import com.odi.util.query.*;
import java.util.Map;
import java.util.Set;
import java.util.Iterator;
import java.util.Collection;

The ObjectStore packages are imported so the code can use them. Without including the query package, I would be unable to perform dynamic run-time queries against the database. The containers, iterators, and collections of the java.util hierarchy are required in order to interface with the OODB.

Code: Phonebook Database and Session Setup
  
  public Phonebook() {
    session = Session.create(null, null);
    session.join();
    try {
      db = Database.open(database, ObjectStore.UPDATE);
    } catch (DatabaseNotFoundException e) {
      db=Database.create(database, ObjectStore.ALL_READ
 | ObjectStore.ALL_WRITE);
    }

The above code ensures that a database is created and that a session to the ObjectStore PSE OODBMS exists. If the database does not already exist, it is created with read and write permissions.

Code: Phonebook Entry Point
  
    Transaction t = Transaction.begin(ObjectStore.UPDATE);
    try {
      entries = (OSHashMap) db.getRoot("entries");
    } catch (DatabaseRootNotFoundException e) {
      db.createRoot("entries", entries = new OSHashMap());
    }
    t.commit(ObjectStore.RETAIN_READONLY);
  }

The above code creates an "entry point" into the OODB. This is similar to defining a relational table name. In the case above, we test to see if the entry point "entries" exist. If not, we create a new OSHashMap with the name "entries," within which we will store our PhonebookEntry objects. The OSHashMap is basically a subclass of the java.util.Map with some added features and persistence capability.

Code: Phonebook Cleanup
  
  public void close() {
    db.close();
    session.terminate();
  }

It is important to properly terminate database and session resource usage before quitting the application. This method should be explicitly called because finalize() does not run predictably, even on shutdown. You can force finalize() to run, but I don't recommend it versus an explicit close() method.

Introduction

Creating A Persistent Class

In this Article
Introduction	Creating A Persistent Class
Building the Application	Performing Updates