JDO is intended for use in two specific architectural spaces. The most straightforward environment is one in which an application directly invokes the services of an implementation. Our simple BusinessPartner example from Chapter 2 works in this way. This is the so-called non-managed environment.
The second environment is that in which the persistence functions of a persistence manager are invoked by application components running within a J2EE application server. This more complicated environment requires that vendors integrate their JDO implementations with the J2EE transaction and connector architectures. This is the so-called managed environment.
3.3.1 Non-managed environment
In the non-managed environment, an application is itself responsible for all interactions with the implementation. This includes configuring the PersistenceManagerFactory, obtaining the PersistenceManager, demarcating transactions (with appropriate begin(), commit() and rollback() invocations), and all persistence operations on instances. Architecturally this is shown in Figure 3.1.
Figure 3.1. The non-managed environment
Applications using JDO in this manner generally configure a factory and obtain a PersistenceManager reference from the factory at startup and retain that reference until the application is closed. Heavily multithreaded applications, however, may rely on the pooling characteristics of the persistence manager factory, which maintains a pool of persistence managers. In such cases the application will get a persistence manager from the factory, use it, and then immediately return it to the pool by invoking its close() method.
3.3.2 Managed environment
In the managed environment JDO is integrated within a J2EE application server. Application components executing within the application server still invoke the PersistenceManager in the usual way. However, they would expect to obtain the PersistenceManagerFactory reference from the Java Naming and Directory Interface (JNDI) context of the application server.
All transaction management is coordinated between JDO and the application server. This enables components to exploit the declarative transaction demarcation model provided by J2EE, or to control it manually with bean-managed transactions (BMT) as appropriate. In the managed environment, applications tend to access data stores through JCA, providing maximum flexibility (Figure 3.2). Finally PersistenceManagers are pooled to reduce resource usage and facilitate scalability. Thus an application component using the services of a PersistenceManager should obtain it from the factory, use it, and close it immediately.
Figure 3.2. Managed environment
3.3.3 Comparison
Table 3.1 illustrates the most important differences between the two environments.
Table 3.1. Non-managed environment vs. managed environment
Non-managed |
Managed |
---|---|
Invoked by an application that is outside a J2EE server |
Invoked by application components inside a J2EE application server |
Application must configure the factory |
Application components obtain a pre-configured factory from JNDI |
Application must demarcate transactions programmatically |
Application components may use declarative (CMT) or programmatic (BMT) transaction demarcation |
Persistence managers are pooled and application components must not hold references to a persistence manager beyond business method invocations |