How Do You Spell Freedom? J-D-O
Does JDO really deliver on the freedom of choice for persisting objects? Test the theory with this experimental application
by John Neal
Posted March 10, 2004
A problem that has existed in software development for some time is that application developers typically have been forced to choose a persistence path to follow relatively early on in the analysis and design process. The various data storage alternatives¡ªflat file, relational database, XML database, object database¡ªhave traditionally not been “plug compatible” with one another. Once the decision is made¡ªwhether or not for the right technical reasons¡ªmomentum will be maintained and the direction will not change for any reason short of a calamitous failure of the application’s persistence layer to meet requirements. It’s an amazing thing that Newton’s first law of motion applies even to the software development process!
Clearly, there is an issue here. The lack of API transparency and plug compatibility across data persistence alternatives has forced developers to make what should be deployment time data persistence decisions early on in the analysis and design phases of the development process. In theory, you’d think that a developer should be able to drag and drop a persistence manager on top of an application at deployment time and have the application do the right thing based on that action. Ahhh, but it’s fun to dream, isn’t it?
In response to this issue, work began on the Java Data Objects (JDO) standard in mid-1999 and resulted in a specification and reference implementation in mid-2002 (see Resources). The fundamental idea behind JDO was to create a common data management API that was independent of the underlying data store. Of course, creating a generic and sufficiently abstract API is one thing; making the rubber meet the road is entirely another. JDO went a step further by abstracting away the specifics of persisting the objects themselves, thus allowing the particulars of which objects need to be persisted and how they should be mapped to disk to be decided much later in the development process than had been possible traditionally.
Many technologies, though, have promised to remedy a variety of software development challenges, but as often as not they have failed to deliver on those promises. JDO offers the promise of freedom of choice on the persistence front, but the “proof is in the pudding,” as they say.
Let’s Experiment
With this background in mind, it seemed that it would be useful to build an application that tested the choice factor. It was important that the application be interesting; simply writing code that performed basic create, read, update, delete (CRUD) operations was neither useful nor interesting. The application needed to model something real, something that anyone could identify with. Additionally, it seemed that it would be interesting to have the application receive and process a data feed from an external source. Finally, because the goal of this endeavor was to understand, the application needed to support experimentation with different transaction models, with and without persistence and with and without JDO.
Having these requirements in mind, I set about building an application and modeling it at a macro level after a production application that I’ve become somewhat familiar with over the years. This particular application receives and stores the price history for all of the securities traded on one of the major stock exchanges in the U.S. At a high level, the application architecture of the test environment looks something like what you see in Figure 1.
The Data Feed Generator (DFG) parses an input file that contains information about the stocks that are to be traded and uses this data to initially populate the stock market. Once the market is populated, a GUI tells the DFG how many connections (each managed by a separate thread) to establish with the Stock Market Server (SMS). The DFG then begins selecting stocks randomly in the market and generates (randomly) new prices for the stocks it selects, passing each new quote to the SMS as a text message of the form . The SMS then locates the security in question and updates the price of the stock. Each stock also keeps a historical record of the price changes that have passed through the system. Therefore, there are a large number of new objects created in addition to the updates of existing objects, all performed with the hope of putting the database through its paces.
The entire application consists of around 25 classes, including the GUI interfaces that were built to support application execution. As indicated previously, there are only a handful of classes that are persisted in the database. The data model for the persistent classes is represented in the diagram shown in Figure 2. The model itself is fairly self-explanatory. As with any good object-oriented (OO) application, the data model was crafted with object navigation in mind rather than relying on direct execution of queries to locate related objects. In fact, the applications perform only one direct query, and that is to locate and retrieve the root StockMarket object at initialization time and which for the sake of simplicity is kept as a singleton in the database.
The SMS transactional behavior is configurable through a properties file. The parameters tell the SMS how frequently to commit (that is, once per second, once every five seconds, and so on), and whether or not to leave the data in memory “hot” across transactional boundaries. Additionally, there are a couple of read-only applications that continually ask for “quotes” because it is interesting to be able to observe how a database responds to interruptions while it is being bombarded with real-time updates.
Amazing
As mentioned previously, a requirement was to be able to run this application in a variety of configurations: both with and without a database and with and without JDO. To accomplish this goal, database behavior required by the application was abstracted into a generic Database class, and then implementations based on this behavior were built for each target configuration. The model that allowed this to be accomplished is shown in Figure 3.
Database is an abstract class that is used by the application. DatabaseNONE consists of empty stubs that allow the DFG and SMS to run without a database. DatabaseJVI allows the applications to run using the Versant object database’s original Java interface (which predates JDO by several years). DatabaseNONE and DatabaseJVI were implemented to provide a baseline for comparison with JDO. DatabaseJDO, of course, allows the application to run using JDO.
As a part of the experiment a series of tests was executed using these persistence management implementations: no database; Versant’s current production Java binding Java Versant Interface (JVI); SolarMetric’s Kodo JDO product interfacing to a leading relational database; and a beta release of Kodo JDO for Versant.
In addition to the variations on the persistence management front, transactional characteristics in the SMS were also varied. Specifically, different tests varied the frequency of commit and whether or not commit flushed data from memory, thus forcing referenced objects to be retrieved again on the next access. (Avoiding the flushing of data is a useful technique to improve performance when there are no expected concurrency issues.)
As an aside, performance results of the various tests were as expected. It has long been a well-understood fact that given any complexity in the data model, object data access against an ODBMS will be fundamentally faster than doing the same bit of work against a relational database (see Resources). Even with the small amount of data complexity present in this application, the object database (both JVI and Kodo JDO for Versant) performed better than the relational database, which was particularly evident when data was flushed from memory with each commit.
Performance measurement, however, was not the ultimate goal of this experiment. Rather, the goal was to determine if JDO would really let a developer wait until application deployment time to make a database decision, even when two disparate data management technologies were in play.
And what were the results of the experiment? First, it is important to note that for the JDO portion of the test, the application was built and the class files were enhanced only once. Second, it was possible to toggle between the Versant ODBMS and the relational database simply by defining different values for:
javax.jdo.
PersistenceManagerFactoryClass
and
javax.jdo.option.
ConnectionDriverName
in the application’s properties file. To put it another way, there was absolutely no recompilation or re-enhancement required whatsoever when I switched between databases. The ease with which this otherwise difficult task could be accomplished simply by using JDO was utterly amazing.
Freedom
Standards come and standards go. Some get legs under them and are widely adopted, while others slowly fizzle and die. As with most standards bodies, the JDO Expert Group¡ªwhich is working within the Java Community Process (JCP) to define the standard¡ªis comprised of representatives from the usual suspects: object and relational database vendors, middleware vendors, and many others who have played a hand in the standardization of the OO paradigm over the years.
The thing that is most interesting about JDO as a standard is that the relational database vendors¡ªeven though they actively participate in the process¡ªare known to privately claim that JDO is something that the object database vendors invented to benefit themselves. It’s a funny thing, once you understand it, that the majority of the JDO implementations to date actively embrace relational technology, sometimes to the exclusion of all other technologies. This dichotomy, when coupled with the fact that JDO provides a common API and delivers on the promise of postponing persistence decisions until deployment time, makes one wonder if there isn’t some innate fear of the choice that JDO provides. It certainly provides some confidence that JDO will not only grow legs, but wings as well. JDO gives application developers the freedom to make the right choice for persistent data management based on knowledge acquired over the development¡ªand even deployment¡ªprocess.
About the Author
John Neal is director of systems engineering at Versant Corporation. Contact John at jneal@versant.com.