6 - Object PErsistence, Relationships, and Queries Flashcards
What are the main goals and challenges of Object Persistence?
Objects whose lifetime exceeds the execution of a an individual program
Goals:
- Abstract application from data sources (MIDW goal of abstraction)
- Data model, query mechanism, API, schema
- DB seen as infrastructure provided by MDW
Challenges
- Impedance mismatch (e.g. relational)
- Structure, relationships, behavior, access paradigm (navigational vs. declarative)
Is the standard JDBC model sufficient for Object Persistence with a ORDBMS? What is missing?
Provides mapping between Java objects and DB Schema, automatically used in get/set object().
Problems:
- No transparency of DB: still requires schema knowledge, DB access, and SQL queries
- References not handled property
Ideal requirements:
- application code only interacts with objects (create, destroy, modify, invoke methods)
- corresponding DB actions performed implicitly by infrastructure (INSERT, SELECT, UPDATE, …)
- mapping from objects to DB performed in deployment phase, classes, IDs, references, relationships
What are the inherent performance problems of objects-persistence?
Not only mapping overhead, but also deficiencies in the programming model: navigational access, no direct support for JOIN
- many configuration and tuning tweaks required
Give an overview of the aspects of Object persistence and the challenges to realise them:
Orthogonal persistence: provide persistence to all data, independent of type (but programmer chooses which objects to persist).
Transitive persistence (by reachability): whole tree of referenced objects is automatically persisted with the root.
Persistence independence (transparent): code that handles persisted and transient object is almost the same:
- Client-side: no impact on interaction with objects (additional actions to persist may occur)
- automatic/ implicit interactions with data stores performed by infrastructure
- Server-side: no special code to implement persistence
Challenges: realizing all aspects requires sophisticated and complex tools
- some aspects may be partially unwanted or inflexible (performance, transitive persistence undesired…)
Give an overview of Design Points in a persistence programming model
In application server: where to separate persistent objects from transient? at distribution level (EJB old) or in prog. lanaguage
Determination of persistence: statically (by type/class -> EJB), semi-dynamic (qualifying objs can be persisted at runtime, dynamically (orthogonal persistence)
Identification of objects: implicit OID vs explicit key (primary key)
Access to object state: member variable or getter/setters
Modification of persisted state: explicit (load/store methods) or automatic (immediate, deferred) or combination
Dependencies/relationships: ref. integrity, lazy vs eager loading, pointer swizzling (map painter structure correctly)
Give an overview of Persistence in CORBA
Persistent object, associated with a PID (diff from object ID): allows multiple PIDs for same obj.
- Representation of objects persistent state
- Describes data location
Persistent object manager: interface for persistence operations, interpretation of PIDs (location)
CORBA object does its own persistence (may use PDS = Persistent Data Service (implicit vs explicit))
PO interface (for explicit): store/delete, connect/disconnect (keep state current / active)
Protocols for persistence services: direct access, ODMG’93, DDO (employed in implementation of PO)
- Too much flexibility and inherent complex (confusing…)
Give an overview of persistence in EJB
All and only entity beans are persistent: tight to the concept of entity
On client-side: transparent persistence - persistence operations are hidden from client (automatic)
Persistence logic separated from business logic (even if automatically generated). Callback methods from home interface)
Container-managed persistence (CMP)
- Persistence-related code is generated automatically
- Fields manipulated through setters (can be propagated to clients in remote interface). More flexibility = lazy loading of attributes, individual att. updates.
- Server-side:
1: defines abstract persistent schema (which fields must be persisted) WHAT
2: mapping to specific DB in deployment phase: HOW (tool support: bottom-up, top-down) - Object state handled by container: callbacks only used to implement additional persistence logic (derived, compression, … )
Bean-managed persistence (BMP)
- Explicit DB-access operations are defined in callback methods (complex mappings, legacy integration). Also explicit finder methods
- No support for container-managed relationships/EJB-QL
What are the main problems with EJB and CORBA persistence models?
Persistence id defined at the level of distributed components: granularity too coarse: too much overhead for local objects.
No support for inheritance
What are the goals and key ideas of JDO persistence?
Standard for Java-based persistence (universal for common Java object)
Orthogonal, transitive persistence of native Java objects (+ inheritance)
Abstract schema and mapping with XML
Semi-dynamic persistence (designed classes may have instance persisted)
Complete transparence fro client-side
Give an overview of the JDO API
Main component: persistence manager (PM): manages all aspects related to persistence and lifecycle of objects, as well as querying and transaction support (created by PersistenceManagerFactory)
Extent: represent all instances of a class (automatic “colletion” that give access to all pers. instances)
Query and transaction interfaces retrieved via PM
Programming Model: take normal object, pass it to PM.makePersistent(obj). Retrieve using object id or query
* after deletion, object stays in memory (just becomes transient)
How does the Byte-Code-Enhancement mechanism of JDO work?
Inject persistence-related infrastructure code into class behavior (compiled code)
Instead of generating code with getter/setters and callbacks (EJB)
Update byte-code in class file according to JDO metadata that specifies the mapping (JDO enhancer: under the hood)
What are the goals of the Java Persistence API and how does it modify the EJB model?
EJB “reaction” to JDO: simplified prog. model, standardized or mapping, inheritance/polymorphism, enhanced query
Scope not restricted to EJB container / app. server, support for third-party persistence engines
Entity-concept (!= entity beans): plain java objects only locally accessible
- Mark objects as entities with annotation/depl. descriptor (no home/local interface, nor further impl. of generated methods)
- Object state is encapsulated: access only through methods
Full flexibility for inheritance aspect and abstract classes
What are the restriction imposed to object in JPA in order to be persisted?
Entities must have (possibly compound) primary key, defined at object root, one per class hierarchy: may not be modified.
Public empty constructor, no final stuff, top-level class
Access to entity state: protected variables or getter/setter (choose one and be consistent)
Only generic collections
Explain the JPA concept of Embeddable class
Represent additional nested state information (eg. Address of a person)
Only visible in context of “container” class
Persistence aspects are handled by container (State of embeddable is saved together with container)
Restrictions : only one level, not in collections, in principle no inheritance
How is the DB-mapping performed in JPA?
Default mapping: class name + attributes -> table name + columns
- can be customized in annotations or depl. descriptor
- can be mapped to more than one table for complex structures
Mapping strategies
- single table with discriminator column: one table for all classes in a hierarchy + type indicator column
- horizontal partitioning: one table per class, columns for all inherited attributes -> only objects of actual type stored.
- vertical partitioning: one table per class, columns just for newly created attributes are stored (i.e., only specific attributes). Objects of subtypes also stored
