There are two major objectives of the JDO architecture: first, to provide application programmers a transparent, Java-centric view of persistent information, including enterprise data and locally stored data; and second, to enable pluggable implementations of data stores into application servers. Data stored in data stores is presented as instances of persistence-capable classes.
JDO defines interfaces and classes to be used by application programmers when using classes whose instances are to be stored in persistent storage (persistence-capable classes), and specifies the contracts between suppliers of persistence-capable classes and the runtime environment (which is part of the JDO implementation).
The JDO architecture defines a standard set of contracts between an application programmer and an JDO vendor. These contracts focus on the view of the Java instances of persistence capable classes.
The JDO PersistenceManagerFactory is the boostrap class for a JDO application. The application gets an instance of the PersistenceManagerFactory by construction or via JDNI lookup.
The application acquires an instance of the JDO PersistenceManager by calling the getPersistenceManager method on an instance of JDO PersistenceManagerFactory.
The JDO PersistenceManager is the primary interface for JDO-aware application components:
A JDO PersistenceManager instance supports any number of JDO instances at a time. It is responsible for managing the identity of its associated JDO instances. A JDO instance is associated with either zero or one JDO PersistenceManager. It will be zero if and only if the JDO instance is transient nontransactional. As soon as the instance is made persistent or transactional, it will be associated with exactly one JDO PersistenceManager.
A JDO PersistenceManager instance supports one transaction at a time, and uses one connection to the underlying data source at a time. The JDO PersistenceManager instance might use multiple transactions serially, and might use multiple connections serially.
Normally, cache management is automatic and transparent. When instances are queried, navigated to, or modified, instantiation of instances and their fields and garbage collection of unreferenced instances occurs without any explicit control. When the transaction in which persistent instances are created, deleted, or modified commits, eviction is automatically done by the transaction completion mechanisms.
Operations on persistent JDO instances at the user's choice might be performed in the context of a transaction. That is, the view of data in the data store is transactionally consistent, according to the standard definition of ACID transactions.
The Transaction interface is used to mark the beginning and end of a application-defined unit of work. The PersistenceManager allows the application to get the instance that manages these transactional boundaries via the currentTransaction method.
The persistent manager instance is a factory for query instances, and queries are executed in the context of the persistent manager instance. The actual query execution might be performed by the JDO PersistenceManager or might be delegated by the JDO PersistenceManager to its data store. The actual query executed thus might be implemented in a very different language from Java, and might be optimized to take advantage of particular query language implementations.
Extents are collections of data store objects managed by the data store, not by explicit user operations on collections. Extent capability is a boolean property of classes that are persistence capable. If an instance of a class that has a managed extent is made persistent via reachability, the instance is put into the extent implicitly.