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.
Difference between revisions of "EclipseLink/DesignDocs/328404"
< EclipseLink | DesignDocs
(→Concepts) |
(→Concepts) |
||
Line 30: | Line 30: | ||
* Currently each persistence unit has a single ServerSession. | * 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. | * Eclipselink core defines SessionBroker class that aggregates several ServerSessions. | ||
** SessionBroker maps each class to a single ServerSession. | ** SessionBroker maps each class to a single ServerSession. | ||
− | * This feature is to define persistence unit that has a SessionBroker instead of 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). | ** Let's call Container persistence unit (or SessionBroker persistence unit). | ||
Revision as of 13:12, 22 October 2010
Contents
Design Specification: Support SessionBroker in JPA
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 B(..)); // insert A into db1; insert B 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).
- Even though ServerSession may use connection pools that connected to different data bases these databases always should share the same database platform.
- ServerSession typically connected to a single data base.
- 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
The two main use cases:
- Unify multiple persistence units (with independent from each other object models).
- Split single persistent unit.
Design Constraints
Design / Functionality
Testing
API
GUI
Config files
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.