The primary target for persistent object systems is to find a convenient mechanism to be able to "persist" (store) in-memory objects. ...and of course to be able to retrieve them.

But this is only part of the story. A system must provide an object/entity model that is used by the developers to deliver the required functionality.

An object model can be reduced to a set of object classes each of which maintains a set of properties and associations with other objects.

It is absolutely essential that minimal constraints are placed on a designer to develop an appropriate object model. Any constraints will result in higher development and maintenance costs, and/or reduced system functionality.

The Generic Persistent Object Model was developed to address not only the functionality of persistence, but also to support mechanisms of object association and lookup.

For example, the constructs used within GPO support one-to-many and many-to-many associations with sets of millions of objects.

You lose the ability to simply persist your own objects - although you can store serializable java objects as property values.

You gain by using or deriving from GPO classes to not only persist your object model but also provide you with support for a fully navigable object model, integrated with transactions, integrity and classification mechanisms.