Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

Object persistence and Java

Get an in-depth look at the issues surrounding object persistence in object-oriented languages

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone

Page 2 of 6

setOfGoodCustomers = setOfAccounts.query(account.inGoodStanding());

While several of the existing object databases are capable of processing such a query style in C++ and Smalltalk, it is difficult for them to do so for larger (say, 500+ gigabytes) collections and more complex query expressions. Several of the relational database companies, such as Oracle and Informix, will soon offer other, SQL-based syntax to achieve the same result.

Persistence and type

An object-oriented language aficionado would say persistence and type are orthogonal properties of an object; that is, persistent and transient objects of the same type can be identical because one property should not influence the other. The alternative view holds that persistence is a behavior supported only by persistable objects and certain behaviors may apply only to persistent objects. The latter approach calls for methods that instruct persistable objects to store and retrieve themselves from persistent storage, while the former affords the application a seamless view of the entire object model -- often by extending the virtual memory system.

Canonicalization and language independence

Objects of the same type in a language should be stored in persistent storage with the same layout, regardless of the order in which their interfaces appear. The processes of transforming an object layout to this common format are collectively known as canonicalization of object representation. In compiled languages with static typing (not Java) objects written in the same language, but compiled under different systems, should be identically represented in persistent storage.

An extension of canonicalization addresses language-independent object representation. If objects can be represented in a language-independent fashion, it will be possible for different representations of the same object to share the same persistent storage.

One mechanism to accomplish this task is to introduce an additional level of indirection through an interface definition language (IDL). Object database interfaces can be made through the IDL and the corresponding data structures. The downside of IDL style bindings is two fold: First, the extra level of indirection always requires an additional level of translation, which impacts the overall performance of the system; second, it limits use of database services that are unique to particular vendors and that might be valuable to application developers.

A similar mechanism is to support object services through an extension of the SQL. Relational database vendors and smaller object/relational vendors are proponents of this approach; however, how successful these companies will be in shaping the framework for object storage remains to be seen.

But the question remains: Is object persistence part of the object's behavior or is it an external service offered to objects via separate interfaces? How about collections of objects and methods for querying them? Relational, extended relational, and object/relational approaches tend to advocate a separation between language, while object databases -- and the Java language itself -- see persistence as intrinsic to the language.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources
  • Download a free copy of ObjectStore PSE for Java version 1.0.1:
    http://www.odi.com/products/pse/psej.html
  • C.J. Date, Introduction to Database Systems, 1990, Fifth Edition Addison-Wesley Publishing Company, New York.
  • This is a classic premier for anyone interested in database technology.
  • Rick Cattel, Object Data Management, 1994, Addison-Wesley Publishing Company, New York.
  • Rick wrote this book way before Java was en vogue and has an excellent treatment of various styles of object storage, from API to distribution to actual disk layout. Rick has gone on to play a important role in the definition of JDBC API.
  • Won Kim (Editor), Modern Database Systems, 1995, ACM Press New York, New York.
  • This book is a collection of papers written on data storage, but has a bias toward demonstrating that object/relational systems will win out over pure object systems. Nonetheless, most anyone who is someone in this business has contributed to this book, so it's worth a look.