3.1 Architecture Within Application JVM
JDO supports a variety of architectures within the application's
JVM context. Your application can have one or multiple
s accessing the same or different
datastores concurrently. Each
own persistent instance
and its own associated
3.1.1 Single PersistenceManager
The simplest JDO application architecture has a single
Figure 3-1. Application using a single PersistenceManager to access a datastore
The application cache is not a specific region of memory, as
Figure 3-1 might imply; it is simply part of the JVM's object heap.
Each persistent class has a field, named
added by the
A persistent instance in the cache can directly reference other
persistent instances in the same cache. You can navigate from one
instance to another using standard Java syntax. Instances of
transient classes (for example, your application class) can also
reference these persistent instances. A persistent instance in the
cache can also reference transient instances of both persistent and
transient classes. The persistent classes
Figure 3-2 shows the relationships between the persistent
, and the
. Each persistent instance contains a
reference to a
, which can manage one or more
persistent instances. Each
reference to its
, which can manage one
contains a reference to its
which can manage one or more
can manage one transaction
Figure 3-2. UML diagram of persistent instance cache
3.1.2 Multiple PersistenceManagers Accessing the Same Datastore
You can instantiate multiple PersistenceManager s in your application from the same or different PersistenceManagerFactory s. Figure 3-3 illustrates an application with two PersistenceManager s from the same PersistenceManagerFactory .
Figure 3-3. Application with multiple PersistenceManagers
Each PersistenceManager manages its own transaction context and application cache. In this particular example, both PersistenceManager s access the same datastore and are from the same JDO implementation. This is the typical architecture for managed environments where different instances of the same component access the same datastore via different PersistenceManager s.
Both PersistenceManager s may have the same datastore instance in their caches, represented by different persistent instances. This architecture provides for transactional isolation of changes made to the same datastore instance by different transactions.
3.1.3 Multiple PersistenceManagers Accessing Different Datastores
Figure 3-4 illustrates
different datastores. These
s could be
from the same or different
Figure 3-4. Application with multiple JDO implementations
3.1.4 Shared Implementation Cache
In addition to the application cache, some JDO implementations also maintain their own persistent instance cache that sits between the application cache and the datastore. Your application does not have access to this implementation cache. Its role is to cache the state of objects from the datastore in memory, so they can be provided to the application without requiring access to the datastore. Use of caches can result in significant performance improvements. A shared implementation cache is most useful when you use nontransactional access, covered in Chapter 14, or optimistic transactions, covered in Chapter 15. When you use datastore transactions, the shared cache is usually bypassed.
18.104.22.168 Shared implementation cache within a single JVM
Figure 3-5 illustrates a shared implementation cache that is managed within a single JVM. It allows each of the PersistenceManager s to quickly access the state of objects that have been accessed from the same datastore.
Figure 3-5. Implementation of a shared cache for transactions accessing the same datastore
For example, if one PersistenceManager accesses a particular instance, the implementation needs to read the instance from the datastore. But if the other PersistenceManager then accesses the same instance, the implementation can use the data in the shared implementation cache and avoid having to access the datastore.
22.214.171.124 Shared implementation cache distributed among JVMs
Several JDO implementations provide a distributed cache architecture, which allows them to migrate the state of objects between JVMs. Figure 3-6 illustrates this architecture.
Figure 3-6. Implementation use of distributed, synchronized caches
Again, the goal with these implementations is to avoid a
datastore access whenever possible. For some systems where multiple
applications may access the same objects, these implementations