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

Difference between revisions of "EclipseLink/Features/Core"

(UnitOfWork)
(Caching)
Line 150: Line 150:
 
* SessionFactory
 
* SessionFactory
  
=== Caching ===
+
== 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
 
* Shared Cache per Server/Database Session
Line 160: Line 162:
 
** FULL
 
** FULL
 
** NONE
 
** NONE
* Query cache usage  
+
* 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 cache usage
 
** Check cache by primary key
 
** Check cache by primary key
 
** Check cache only
 
** Check cache only
 
** Check cache then database
 
** Check cache then database
 
** Check cache only
 
** Check cache only

Revision as of 21:24, 30 October 2007

PAGE UNDER CONSTRUCTION

EclipseLink Core Functionality

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

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 dbetween all of these persistence services as related to dealing with a persistent class.

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.
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
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
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.

Transactions

The EclipseLink transaction model is generally used through the UnitOfWork.

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

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
  • 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 cache usage
    • Check cache by primary key
    • Check cache only
    • Check cache then database
    • Check cache only

Back to the top