71 Understanding the Persistence Layer

This chapter describes the following:

Overview of the Persistence Layer
Sessions
Data Access
Cache
Queries and Expressions
Transactions

Overview of the Persistence Layer

The purpose of your application's persistence layer is to use a session (see "Sessions") at run time to associate mapping metadata (see "Mapping Metadata") and a data source (see "Data Access") in order to create, read, update, and delete persistent objects using the TopLink cache (see "Cache"), queries and expressions (see "Queries and Expressions"), as well as transactions (see "Transactions").

Sessions

A session is the primary interface between the client application and the TopLink runtime, and represents the connection to the underlying data source.

For non-CMP projects, TopLink offers several different session types (see "Understanding TopLink Sessions"), each optimized for different design requirements and architectures. The most commonly used session is the server session–a session that clients access on the server through a client session. The server session provides a shared cache and shared connection resources.

For CMP projects, the TopLink runtime creates and uses a session internally, but your application does not acquire or use this session directly. Depending on the application server you use, you can specify some of the parameters for this internal session (see "<J2EE-Container>-ejb-jar.xml File").

Data Access

The login (if any) associated with a session determines how the TopLink runtime connects to the project's data source.

A login includes details of data source access, such as authentication, use of connection pools, and use of external transaction controllers. A login (an instance of Login interface) owns a data source platform.

A platform includes options specific to a particular data source, including such as binding, use of native SQL, use of batch writing, and sequencing. For more information about platforms, see "Data Source Platform Types".

For projects that do not persist to a data source, a login is not required. For projects that do persist to a data source, a login is always required.

For relational and For more information, see "Understanding Data Access"

Cache

By default, a TopLink session provides an object level cache that guarantees object identity and enhances performance by reducing the number of times the application needs to access the data source. TopLink provides a variety of cache options, including locking, refresh, invalidation, isolation, and coordination. Using cache coordination, you can configure TopLink to synchronize changes with other instances of the deployed application. You configure most cache options at the session level. You can also configure cache options on a per-query basis, or on a descriptor to apply to all queries on the reference class.

For more information, see "Understanding the Cache"

Queries and Expressions

TopLink provides several object and data query types, and offers flexible options for query selection criteria, including the following:

TopLink expressions
EJB QL
SQL
Stored procedures
Query by example

With these options, developers can build any type of query. Oracle recommends using predefined queries to define application queries. Predefined queries are held in the project metadata and referenced by name. This simplifies application development and encapsulates the queries to reduce maintenance costs.

When using EJB entity beans, you can code finders using only EJB QL (in addition to any of the other TopLink query options), enabling the application to comply with the J2EE specification.

Regardless of the architecture or persistent entity type, you are free to use any of the query options. TopLink Workbench provides the simplest way to define queries. Alternatively, you can build queries in code, using the TopLink API.

For more information, see the following:

Transactions

TopLink provides the ability to write transactional code isolated from the underlying database and schema by using a unit of work.

The unit of work isolates changes in a transaction from other threads until it successfully commits the changes to the database. Unlike other transaction mechanisms, the unit of work automatically manages changes to the objects in the transaction, the order of the changes, and changes that might invalidate other TopLink caches. The unit of work manages these issues by calculating a minimal change set, ordering the database calls to comply with referential integrity rules and deadlock avoidance, and merging changed objects into the shared cache. In a clustered environment, the unit of work also synchronizes changes with the other servers in the coordinated cache.

If an application uses EJB entity beans, you do not access the unit of work API directly, but you still benefit from its features: the integration between the TopLink runtime and the J2EE container automatically uses the unit of work.

For more information, see "Understanding TopLink Transactions".