Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

EclipseLink/Features/Core

< EclipseLink‎ | Features
Revision as of 10:51, 7 December 2007 by Rick.sapir.oracle.com (Talk | contribs) (more xrefs to elug)

These core infrastructure features are leveraged by multiple persistence services.

Mapping

EclipseLink offers developers the ability to map a persistent POJO domain model. These persistent object types known as entities allow developers to design and implement a domain model without coupling to a particular persistence service. EclipseLink allows the domin model to be implemented without:

  • inheriting from a common persistent superclass
  • implementing a common persistence interface
  • implement any persistence functionality within the entity classes
  • Attribute Accessors: Controls how EclipseLink will access persistent values from a mapped entity
    • Field: Specifies direct field access to the mapped value. This is the default
    • Method: Allows any get/set method pair to be specified for use

See Overview of EclipseLink Mappings in the EclipseLink User's Guide for more information.


Class Descriptor

The ClassDescriptor represents the mapping of a single persistent entity type to one or more data source artifacts. The ClassDescriptor is the abstract parent class to the concrete descriptor types used in Object-Relational (JPA and Native), MOXy, and EIS. It contains the common state and functionality share between all of these persistence services as related to dealing with a persistent class.

See Introduction to Descriptors in the EclipseLink User's Guide for more information.


Instantiation Policy

By default a ClassDescriptor makes use of the default (zero-argument) constructor for the entity type when constructing new instances. This constructor must be present if additional constructors exist but the default constructor does not have to be public. Using reflection and the JVM's security policy EclipseLink can invoke this constructor it is protected or private as well. Application can override this default by providing a factory for the instantiation policy to use to invoke alternative constructors or to perform additional operations during the creation of a new instance.

  • Factory using static method
  • Factory specified with a factory instance and method name.


See Configuring Instantiation Policy in the EclipseLink User's Guide for more information.


Clone/Copy Policy

The Clone/Copy policy of a class descriptor specifies how clones are constructed when needed (i.e. When building working copies or backup copies in the UnitOfWork). This is similar to the instantiation policy using the default constructor by default but allowing the specification of an alternate method or factory for the creation of clones.

    • Factory
    • entity clone method


Inheritance Policy

Eclipselink provides support for inheritance in two ways:

  • Inheritance of attributes from a non-persistent class: Used when common attributes are abstracted to a root class but that class does not map to a shared table for the hierarchy and is therefore not persistent on its own.
  • Data source inheritance: Where the underlying data source has a structure maintaining the various sets of attributes for each level of inheritance with a root structure containing the common attributes and a way to indicate which sub-class to use.
  • Indicator Strategy
    • Field
      • Coded values
      • Class name
    • Class extraction method


See Descriptors and Inheritance in the EclipseLink User's Guide for more information.



Wrapper Policy

Enables the configuration of a common wrapper to be placed around all objects read and to interpret the wrapped objects when being written.


Descriptor Query Manager
    • Named Queries
    • Custom SQL or queries for default CRUD operations
    • Query keys

See Introduction to EclipseLink Queries in the EclipseLink User's Guide for more information.


Descriptor Event Manager

The ClassDescriptor's event manager allows entity life-cycle events to be called on a listener (either the entity itself or more commonly an implementor of the DescriptorEventListener interface).

  • API
    • SessionEventListener () interface
      • preInsert
      • aboutToInsert
      • postInsert
      • preUpdate
      • aboutToUpdate
      • postUpdate
      • preWrite
      • postWrite
      • preDelete
      • aboutToDelete
      • postDelete
      • postClone
      • postBuild
      • prePersist
      • preRemove
      • postMerge
      • preUpdateWithChanges
    • SessionEventAdapater () implementor of SessionEventListener: By subc-lassing this abstract class developers can avoid implementing all of the event methods. The implementations of these methods in SessionEventAdapter have no behaviour.


See Descriptor Event Manager in the EclipseLink User's Guide for more information.


Transactions

The EclipseLink transaction model is generally used through the UnitOfWork.

See EclipseLink Transactions in the EclipseLink User's Guide for more information.


Modes

  • RESOURCE_LOCAL: Using the native (i.e. JDBC) transaction control of the data source
  • JTA: Participating as a listener within a container's JTA data source requiring the use of its connection pools

UnitOfWork

    • Transaction isolated cache
    • Registration of objects
      • Register: New or existing objects
      • Register New Object
      • Register Existing Object
    • Merge
      • Deep Merge
      • Shallow Merge
      • Merge with relationships
    • Change Tracking
      • Deferred: Changes are detected at commit/flush by comparing working copy against backup copy made when object is registered into UnitOfWork
      • Object mark-dirty
      • Attribute Change Tracking
    • Nested UnitOfWork
    • UnitOfWork.beginEarlyTransaction: Force the UnitOfWork to initiate the database transaction.
  • Key Benefits of the UnitOfWork
    • Change Tracking: Claculation of a minimal change-set at commit or flush points used to apply changes to the data source
      • Deferred: Using a working copy and backup copy of the shared persistent entity changes are calculated at commit time through comparison
      • Change Tracking: Optimized approaches available through custom API in the persistent entity classes or more commonly accessed through byte code weaving (dynamic or static)
        • Attribute: Track changes by updating the UnitOfWork's change set when changes are applied
        • Object: Track changes at the object level using a mark-dirty flag
    • Consistent DML Ordering based on referential integrity rules: Helps rduce contention on the database that could lead to deadlocks

Direct Transaction Management

When using a single dedicated connection within a DatabaseSession it is possible to directly control the transaction. This allows the developer access to the underlying transaction control, assuming that RESOURCE_LOCAL transaction mode is in use. This functionality forgoes many of the tracking, isolation, and in-memory rollback benefits of the UnitOfWork.

    • DatabaseSession API
      • beginTransaction
      • commitTransaction
      • rollbackTransaction



Sessions

The primary API for the EclipseLink native access is the session.

  • Common: The following features are common to all session types
    • Read: Simple calls to execute
      • readObject
      • readAllObjects
    • Acquire UnitOfWork
    • Copy Object
    • IdentityMapAccessor
  • Server Session: Is used for
  • Client Session: Used
  • Database Session
  • Session Broker
  • UnitOfWork: Is the primary native transaction API but also implements the common session API


See Using EclipseLink Sessions in the EclipseLink User's Guide for more information.


Session Management

  • SessionManager
  • SessionFactory


Caching

EclipseLink's caching is one of its most unique and powerful features. EclipseLink leverages a multi-level entity cache storing the mapped object enabling instance sharing within a transaction, client, or across the application. It is very flexible in its configuration and use and offers developers the ability to easily customize its behaviour to meet the application's requirements.

  • Shared Cache per Server/Database Session
  • Isolated Cache per client
  • Cache Type and initial/default size
    • SOFT-WEAK
    • HARD-WEAK
    • WEAK
    • FULL
    • NONE


See Caching with EclipseLink in the EclipseLink User's Guide for more information.


Invalidation/Expiration

    • Time to live
    • Fixed time(s) of day
    • Accessible through API calls

Cache Coordination

    • Communication Protocol
      • JMS
      • RMI & RMI over IIOP
      • CORBA
    • Modes: On a per entity type basis a developer can customize what is sent across in cache coordindation commands
      • SYNCHONIZE: Send all changes for the entity and apply them in other nodes where the entity exists in the cache. New instances are only created in other caches when required to complete a populated or non-indirect relationship form an existing entity.
      • SYNCHONIZE + NEW
      • INVALIDATE
      • NONE
    • Ability to optionally reconnect or disconnect remote connection on failures

Query Usage of Cache

Object queries have default cache usage and flexible configurations allowing use case specific customizations of these behaviours.

  • Cache Usage: How the cache is used when executing a query. Can potentially eliminate queries to the data store all together
    • Check cache for Primary Key expressions (ReadObjectQuery default)
    • Check Cache then database (ReadObjectQuery Only)
    • Check Database Only
    • Check Cache Only (in-memory querying)

Additionally developer require control for how the results retrieved form the database for object queries aqre processed against the cache.

  • Refresh
    • Cascade refresh
  • Don't Use Cache

Back to the top