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/DesignDocs/328404"

(Config files)
(Requirements)
Line 51: Line 51:
 
*** User starts with several independent persistence units, creates a new SessionBroker persistent unit that aggregates ServerSessions defined in the original persistence units.
 
*** User starts with several independent persistence units, creates a new SessionBroker persistent unit that aggregates ServerSessions defined in the original persistence units.
 
*** The original persistence units remain unchanged, could still be used individually.
 
*** The original persistence units remain unchanged, could still be used individually.
 +
*** Limitation: the original persistence units and the SessionBroker persistent unit should be all defined in a single jar file.
  
 
** Split single persistent unit.
 
** Split single persistent unit.

Revision as of 14:19, 22 October 2010

Design Specification: Support SessionBroker in JPA

ER 328404

Document History

2010/10/22 Andrei Ilitchev Initial Version

Project overview

The goal is to allow for different classes contained in a single persistence context to be mapped to different databases.

em.persist(new A(..));
em.persist(new Z(..));
// insert A into db1; insert Z into db2:
// the two different data bases possibly from different vendors
em.flush();

Concepts

  • Currently each persistence unit has a single ServerSession.
    • ServerSession typically connected to a single data base.
      • Even though ServerSession may use connection pools that connected to different data bases these databases always should share the same database platform.
        • That means it's impossible to use ServerSession to map different classes to different types of data bases (say, Oracle and MySQL).
  • Eclipselink core defines SessionBroker class that aggregates several ServerSessions.
    • SessionBroker maps each class to a single ServerSession.
    • Each ServerSession connected to a different data base.
      • These ServerSessions are not required to share the same database platform.
      • Therefore different classes mapped to different data bases, too.
  • This feature is going to define persistence unit that has a SessionBroker instead of ServerSession.
    • Let's call Container persistence unit (or SessionBroker persistence unit).

Requirements

  • SessionBroker persistence unit must be defined in persistence.xml (as any other persistence unit).
  • The two main use cases:
    • Unify multiple persistence units (with independent from each other object models).
      • User starts with several independent persistence units, creates a new SessionBroker persistent unit that aggregates ServerSessions defined in the original persistence units.
      • The original persistence units remain unchanged, could still be used individually.
      • Limitation: the original persistence units and the SessionBroker persistent unit should be all defined in a single jar file.
    • Split single persistent unit.
      • User starts with a single persistence unit, alters it to become SessionBroker persistence unit.

Design Constraints

Design / Functionality

  • ServerSessions that are aggregated by a SessionBroker persistence unit are "invisible" outside of it:
    • don't have EntityManagerFactories associated with them;
    • EntityManagerSetupImpl used for their creation are not kept;
    • these sessions are not stored in SessionManager.

Testing

API

GUI

Config files

  • Proposed configuration of SessionBroker persistence unit is done entirely through Persistence Unit properties.
    • Properties extension usage and naming patterns.
// Property with set values
eclipselink.define.my-set-property.value1 -> ""
eclipselink.define.my-set-property.value2 -> ""
...
eclipselink.define.my-set-property.valueN -> ""
 
// Converted to a Set:
my-set-property = {value1, value2, ..., valueN};
 
 
// Property with Map value
eclipselink.define.my-map-property.value1.key1 -> ""
eclipselink.define.my-map-property.value2.key2 -> ""
...
eclipselink.define.my-map-property.valueN.keyN -> ""
 
// Converted to a Map:
my-property = {key1 -> value1; key2 -> value2; ..., keyN -> valueN};
 
// Suggested naming convention:
// let's use "eclipselink.define" prefix for these "value-less" properties.


  • The two main use cases:
    • Unify multiple persistence units (with independent from each other object models).

There are two predefine independent persistence units: puABC (that maps classes A, B, C) and puXYZ (that maps classes X, Y, Z). None of A, B, C classes references any of X, Y, Z classes and vise verse.

      • User starts with several independent persistence units, creates a new SessionBroker persistent unit that aggregates ServerSessions defined in the original persistence units.
      • The original persistence units remain unchanged, could still be used individually.
    • Split single persistent unit.
      • User starts with a single persistence unit, alters it to become SessionBroker persistence unit.

Documentation

Open Issues

This section lists the open issues that are still pending that must be decided prior to fully implementing this project's requirements.

Issue # Owner Description / Notes

Decisions

This section lists decisions made. These are intended to document the resolution of open issues or constraints added to the project that are important.

Issue # Description / Notes Decision

Future Considerations

During the research for this project the following items were identified as out of scope but are captured here as potential future enhancements. If agreed upon during the review process these should be logged in the bug system.

Back to the top