7.4 Managed and Non-Managed Environments


7.4 Managed and Non-Managed Environments

The terms managed and non-managed have been used at various points in the book to differentiate between traditional two-tier Java applications and multi- tier Java applications.

A two-tier Java application explicitly connects to the underlying datastore (which constitutes the second tier) and begins and ends its own local transactions. A two-tier application typically starts, does something at the bequest of a user and ends.

A multi-tier Java application requests connections from a connection manager and may delegate transaction control to an external coordinator. This coordinator begins and ends transactions implicitly, potentially coordinating multiple different data sources into a single distributed transaction. A multi-tier application typically runs continuously, processing requests that its receives from other applications. Servlets, EJBs, and applications that use RMI or CORBA are all examples of multi-tier applications.

7.4.1 Connection management

To interact with the underlying datastore, a JDO application must get a connection. A two-tier application typically requires a connection for the duration of the application, during which time it begins and ends many transactions. A multi-tier application typically requires a connection for the duration of a single transaction only. For this reason, multi-tier applications rely on resource pooling to avoid connections being continuously opened and closed. Instead, once connections are opened, they are managed in a resource pool. Each time a multi-tier application requires a connection to process a request, one is allocated from the pool; when finished, the connection is given back to the pool. Although typically used by multi-tier applications, some two-tier applications can also benefit from resource pooling.

7.4.1.1 Two-tier applications

A two-tier Java application constructs a PersistenceManagerFactory , gets one or more PersistenceManager instances, and closes them when finished. The act of getting a PersistenceManager instance and closing it may or may not correlate with physically opening and closing connections to the underlying datastore.

Depending on the JDO implementation being used and how it is configured, the PersistenceManagerFactory may pool the underlying datastore connections or PersistenceManager instances. This means that when the application closes a PersistenceManager instance, it doesn't physically close anything, but rather gives back the resources to the PersistenceManagerFactory to be reused. All this is transparent to the application, which simply gets a PersistenceManager instance when it needs one and closes it when it is finished.

A JDO implementation may also allow use of external connection factories. If configured to use an external connection factory, the PersistenceManagerFactory relies on the external factory to pool datastore connections. It requests a connection when needed and returns it to the factory when finished. See the ConnectionFactory and ConnectionFactoryName properties on PersistenceManagerFactory for more details on using external connection factories.

Connection pooling is more typically useful for multi-tier applications, but some multi-threaded, two-tier applications may benefit from pooling also, particularly those that can have many threads where a thread doesn't necessarily need a PersistenceManager instance all the time. By pooling, an application can reduce the resources it needs at any given time.

7.4.1.2 Multi-tier applications

A multi-tier application looks up a PersistenceManagerFactory (typically using JNDI), from which it gets one or more PersistenceManager instances.

If used in a J2EE runtime environment, a PersistenceManagerFactory instance is no longer responsible for connection management; instead, it relies on the J2EE container to pool connections and manage the quality of service associated with use of those connections.

Most JDO implementations use the J2EE Connector Architecture (JCA) as the means by which the PersistenceManagerFactory instance interacts with the J2EE container. The JCA resource adapter provided with a JDO implementation is configured and deployed into a J2EE runtime environment. The PersistenceManagerFactory instance retrieved via JNDI then delegates connection management to the J2EE container.

The JDO specification does not mandate that a JDO implementation use JCA; an implementation may choose a different way of integrating with a J2EE container. Although how the JDO implementation is configured and deployed may differ , the application itself remains the same. It looks up a PersistenceManagerFactory instance from which it gets PersistenceManager instances.

Non-J2EE multi-tier applications must ensure that the JDO implementation being used implements its own connection pooling.

7.4.2 Transaction management

Transactions provide the context within which persistent objects are stored in the datastore and retrieved again. A two-tier application typically begins and ends transactions explicitly, while a multi-tier application may delegate transaction control to an external coordinator, in which case the coordinator begins and ends transactions implicitly.

7.4.2.1 Two-tier applications

A two-tier application gets a Transaction instance from a PersistenceManager , and uses it to explicitly begin and end transactions.

7.4.2.2 Multi-tier applications

A multi-tier application can delegate transaction control to an external coordinator, typically the Java Transaction Service (JTS). When using an external coordinator, transactions are automatically controlled.

If used in a J2EE runtime environment, a PersistenceManagerFactory instance ensures that a PersistenceManager instance is associated with the externally coordinated transaction (if there is one) when it is retrieved. This is relevant primarily for EJBs. If a method has been declared as transactional, then when the Bean method gets its PersistenceManager instance from the PersistenceManagerFactory , the PersistenceManagerFactory returns a PersistenceManager instance associated with the external transaction. The external coordinator then implicitly begins and ends the transaction.

A multi-tier application doesn't have to delegate transaction management to an external coordinator. In this case, the application explicitly begins and ends transactions via the Transaction interface. This is relevant for Servlets or EJBs with non-transactional methods .

For transaction management, most JDO implementations use JCA as the means by which the PersistenceManagerFactory interacts with the J2EE container.

However, this is not mandated , and an implementation may use a different mechanism.

Non-J2EE applications that require external coordination of transactions must ensure that the JDO implementation being used supports the Java Transaction APIs (JTA) so it can be integrated with JTS.



Core Java Data Objects
Core Java Data Objects
ISBN: 0131407317
EAN: 2147483647
Year: 2003
Pages: 146

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net