This chapter provides the conceptual overview of the persistence layer of a TopLink application.
This chapter includes the following section:
The purpose of your application's persistence layer is to use a session (see Section 86.1.1, "Sessions") at run time to associate mapping metadata (see Section 2.4.3.1, "Mapping Metadata") and a data source (see Section 86.1.2, "Data Access") in order to create, read, update, and delete persistent objects using the TopLink cache (see Section 86.1.3, "Cache"), queries and expressions (see Section 86.1.4, "Queries and Expressions"), as well as transactions (see Section 86.1.5, "Transactions").
This section introduces the following persistence layer concepts:
A session is the primary interface between the client application and the TopLink runtime, and represents the connection to the underlying data source.
For POJO projects, TopLink offers several different session types (see Chapter 87, "Introduction to 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 Section 9.1.4, "JAVA-EE-CONTAINER-ejb-jar.xml File").
In JPA projects, sessions are used internally as follows:
an EntityManagerFactory wraps a ServerSession;
an EntityManager wraps a UnitOfWork and a ClientSession.
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, such as binding, use of native SQL, use of batch writing, and sequencing, that are specific to a particular data source. For more information about platforms, see Section 96.1.3, "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 Chapter 96, "Introduction to Data Access"
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 Chapter 102, "Introduction to Cache"
TopLink provides several object and data query types, and offers flexible options for query selection criteria, including the following:
TopLink expressions
JP QL
SQL
Stored procedures
Query by example
With these options, you 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.
Regardless of the architecture or persistent entity type, you are free to use any of the query options. Oracle JDeveloper TopLink Editor and TopLink Workbench provide the simplest way to define queries. Alternatively, you can build queries in code, using the TopLink API.
For more information, see the following:
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 Java EE container automatically uses the unit of work.
For more information, see Chapter 113, "Introduction to TopLink Transactions".