Skip Headers
Oracle TopLink Developer's Guide
10g Release 3 (10.1.3)
B13593-01
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

Understanding Object Persistence

This section includes a brief description of relational mapping and provides important information and restrictions to guide object and relational modeling. This information is useful when building TopLink applications.

This section includes information on the following:

These sections contain additional detail on these features, and explain how to implement and use them with TopLink.

Application Object Model

Object modeling refers to the design of the Java classes that represent your application objects. With TopLink, you can use your favorite integrated development environment (IDE) or Unified Modeling Language (UML) modeling tool to define and create your application object model.

Any class that registers a descriptor with a TopLink database session is called a persistent class. TopLink does not require that persistent classes provide public accessor methods for any private or protected attributes stored in the database. Refer to "Persistent Class Requirements" for more information.

Data Storage Schema

Your data storage schema refers to the design that you implement to organize the persistent data in your application. This schema refers to the data itself–not the actual data source (such as a relational database or nonrelational legacy system).

During the design phase of the TopLink application development process (see "Typical Development Stages"), you should decide how to implement the classes in the data source. When integrating existing data source information, you must determine how the classes relate to the existing data. If no legacy information exists to integrate, decide how you will store each class, then create the necessary schema.

You can also use TopLink Workbench (see Chapter 5) or database schema manager (see Chapter 6) to create the necessary information.

Primary Keys and Object Identity

When making objects persistent, each object requires an identity to uniquely identify it for storage and retrieval. Object identity is typically implemented using a unique primary key. This key is used internally by TopLink to identify each object, and to create and manage references. Violating object identity can corrupt the object model.

In a Java application, object identity is preserved if each object in memory is represented by one, and only one, object instance. Multiple retrievals of the same object return references to the same object instance–not multiple copies of the same object.

TopLink supports multiple identity maps to maintain object identity (including composite primary keys). Refer to "Cache Type and Object Identity" for additional information.

Mappings

TopLink uses the metadata produced by TopLink Workbench (see "Understanding TopLink Metadata") to describe how objects and beans map to the data source. This approach isolates persistence information from the object model–developers are free to design their ideal object model, and DBAs are free to design their ideal schema.

Developers use TopLink Workbench to create and manage the mapping information. At run time, TopLink uses the metadata to seamlessly and dynamically interact with the data source, as required by the application.

TopLink provides an extensive mapping hierarchy that supports the wide variety of data types and references that an object model might contain. For more information, see "Understanding Mappings".

Foreign Keys and Object Relationships

A foreign key is a combination of columns that reference a unique key, usually the primary key, in another table. Foreign keys can be any number of fields (similar to primary key), all of which are treated as a unit. A foreign key and the primary parent key it references must have the same number and type of fields.

Foreign keys represents relationships from a column or columns in one table to a column or columns in another table. For example, if every Employee has an attribute address that contains an instance of Address (which has its own descriptor and table), the one-to-one mapping for the address attribute would specify foreign key information to find an address for a particular Employee.

Refer to "Configuring Table and Field References (Foreign and Target Foreign Keys)" for more information.

Inheritance

Object-oriented systems allow classes to be defined in terms of other classes. For example: motorcycles, sedans, and vans are all kinds of vehicles. Each of the vehicle types is a subclass of the Vehicle class. Similarly, the Vehicle class is the superclass of each specific vehicle type. Each subclass inherits attributes and methods from its superclass (in addition to having its own attributes and methods).

Inheritance provides several application benefits, including the following:

  • Using subclasses to provide specialized behaviors from the basis of common elements provided by the superclass. By using inheritance, you can reuse the code in the superclass many times.

  • Implementing abstract superclasses that define generic behaviors. This abstract superclass may define and partially implement behavior, while allowing you to complete the details with specialized subclasses.

Refer to "Configuring Inheritance for a Child (Branch or Leaf) Class Descriptor" and "Configuring Inherited Attribute Mapping in a Subclass" for detailed information on using inheritance with TopLink.

Concurrency

To have concurrent clients logged in at the same time, the server must spawn a dedicated thread of execution for each client. J2EE application servers do this automatically. Dedicated threads enable each client to work without having to wait for the completion of other clients. TopLink ensures that these threads do not interfere with each other when they make changes to the identity map or perform database transactions. Using the TopLink UnitOfWork class, your client can make transactional changes in an isolated and thread safe manner. The unit of work manages clones for the objects you modify to isolate each client's work from other concurrent clients and threads. The unit of work is essentially an object-level transaction mechanism that maintains all of the ACID (Atomicity, Consistency, Isolation, Durability) transaction principles as a database transaction. For more information on the unit of work, see "Understanding TopLink Transactions".

TopLink supports configurable optimistic and pessimistic locking strategies to let you customize the type of locking that the TopLink concurrency manager uses. For more information, see "Understanding Descriptors and Locking".

Caching

TopLink caching improves application performance by automatically storing data returned as objects from the database for future use. This caching provides several advantages:

  • Reusing Java objects that have been previously read from the database minimizes database access

  • Minimizing SQL calls to the database when objects already exist in the cache

  • Minimizing network access to the database

  • Setting caching policies a class-by-class and bean-by-bean basis

  • Basing caching options and behavior on Java garbage collection

TopLink supports several caching polices to provide extensive flexibility. Developers can fine-tune the cache for maximum performance, based on individual application performance. Refer to Part XVIII, "Cache" for complete information.

Nonintrusive Persistence

The TopLink nonintrusive approach of achieving persistence through a metadata architecture (see "Understanding TopLink Metadata") means that there are almost no object model intrusions.

To persist Java objects, TopLink does not require any of the following:

  • Persistent superclass or implementation of persistent interfaces

  • Store, delete, or load methods required in the object model

  • Special persistence methods

  • Generating source code into or wrapping the object model

When using CMP entity beans, TopLink does not require any additional intrusion to the object model, other than the CMP specification requirements.

See "Building and Using the Persistence Layer" for additional information on this nonintrusive approach.

Indirection

An indirection object takes the place of an application object so the application object is not read from the database until it is needed. Using indirection allows TopLink to create stand-ins for related objects. This results in significant performance improvements, especially when the application requires the contents of only the retrieved object rather than all related objects.

Without indirection, each time the application retrieves a persistent object, it also retrieves all the objects referenced by that object. This may result in lower performance for some applications.


Note:

Oracle strongly recommends that you use indirection in all situations.

TopLink provides several indirection models, such as proxy indirection, transparent indirection, and value holder indirection. TopLink also provides indirection support for EJB (see "Indirection and EJB").

See "Indirection" for more information.