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

(Proposed Config)
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
==Partitioning==
 +
I think it is incorrect to consider the SessionBroker as a partitioning solution.  The purpose of the SessionBroker is for Data Integration, not Data Partitioning.  The SessionBroker was designed as a Data Integration solution, initially to support integrating a legacy (mainframe) database (or EIS) with new relational data.  Also to provide an aggregated view on a set of a corporation's databases.  It is entirely designed to work with heterogeneous data sources, it goal is to provide an integrated view on heterogeneous data, not to provide partitioning, fail-over or scalability.  It should not be relabeled or marketed as a partitioning solution, only as a Data Integration solution.  We do need a Data Partitioning solution, such a solution would have very different goals and requirements.
 +
:[[User:James.sutherland.oracle.com|James.sutherland.oracle.com]] 14:33, 4 November 2010 (UTC)
 +
 
==Session Type==
 
==Session Type==
 
The property to set the Session type, such as using a DatabaseSession should not be, "eclipselink.jdbc.single-connection", but "eclipselink.session.type".  For SessionBroker, this should be of type "SessionBroker", "DatabaseSession" could also be supported, the default would be "ServerSession", but other types could be supported, including a user defined class "<package>.<class>".
 
The property to set the Session type, such as using a DatabaseSession should not be, "eclipselink.jdbc.single-connection", but "eclipselink.session.type".  For SessionBroker, this should be of type "SessionBroker", "DatabaseSession" could also be supported, the default would be "ServerSession", but other types could be supported, including a user defined class "<package>.<class>".
Line 51: Line 55:
 
<properties>
 
<properties>
 
                 <!-- Implicitly define a secondary data source named 'addr-ds' -->
 
                 <!-- Implicitly define a secondary data source named 'addr-ds' -->
<property name="eclipselink.jdbc.driver.addr-ds" value="oracle."/>
+
<property name="eclipselink.jdbc.driver.addr-ds" value="oracle..."/>
 
<property name="eclipselink.jdbc.url.addr-ds" value="jdbc:"/>
 
<property name="eclipselink.jdbc.url.addr-ds" value="jdbc:"/>
 
<property name="eclipselink.jdbc.user.addr-ds" value="scott"/>
 
<property name="eclipselink.jdbc.user.addr-ds" value="scott"/>
 
<property name="eclipselink.jdbc.password.addr-ds" value="tiger"/>
 
<property name="eclipselink.jdbc.password.addr-ds" value="tiger"/>
 +
 +
                <!-- Implicitly define another data source named 'project-ds' -->
 +
<property name="eclipselink.jdbc.driver.project-ds" value="oracle..."/>
 +
<property name="eclipselink.jdbc.url.project-ds" value="jdbc:"/>
 +
<property name="eclipselink.jdbc.user.project-ds" value="scott"/>
 +
<property name="eclipselink.jdbc.password.project-ds" value="tiger"/>
 
</properties>
 
</properties>
 
</persistence-unit>
 
</persistence-unit>
 
</source>
 
</source>
 +
 +
 +
=== Proposed Config - extended ===
 +
 +
The logical conclusion of the above approach would be an option to define split data sources in EclipseLink ORM xml, too.
 +
 +
<source lang="xml">
 +
<entity class="eclipselink.example.jpa.employee.model.Employee" />
 +
<entity class="eclipselink.example.jpa.employee.model.Address" data-source="addr-ds" />
 +
<entity class="eclipselink.example.jpa.employee.model.Project" data-source="proj-ds" />
 +
<entity class="eclipselink.example.jpa.employee.model.SmallProject" data-source="proj-ds" />
 +
<entity class="eclipselink.example.jpa.employee.model.LargeProject" data-source="proj-ds" />
 +
<entity class="eclipselink.example.jpa.employee.model.HugeProject" data-source="proj-ds" />
 +
 +
<data-source name="addr-ds">
 +
    <jta-data-source>Ds1_JTA</jta-data-source>
 +
    <nonjta-data-source>Ds1</nonjta-data-source>
 +
</data-source>
 +
<data-source name="proj-ds">
 +
    <jta-data-source>Ds2_JTA</jta-data-source>
 +
    <nonjta-data-source>Ds2</nonjta-data-source>
 +
</data-source>
 +
</source>
 +
 +
To define internal connection pools:
 +
<source lang="xml">
 +
<data-soure name="addr-ds">
 +
<properties>
 +
<property name="eclipselink.jdbc.driver" value="oracle..."/>
 +
<property name="eclipselink.jdbc.url" value="jdbc:"/>
 +
<property name="eclipselink.jdbc.user" value="scott"/>
 +
<property name="eclipselink.jdbc.password" value="tiger"/>
 +
<properties>
 +
</data-soure
 +
<data-soure name="proj-ds">
 +
<properties>
 +
<property name="eclipselink.jdbc.driver" value="mysql..."/>
 +
<property name="eclipselink.jdbc.url" value="jdbc:"/>
 +
<property name="eclipselink.jdbc.user" value="user2"/>
 +
<property name="eclipselink.jdbc.password" value="password2"/>
 +
<properties>
 +
</data-soure>
 +
</source>
 +
 +
The secondary "data-source" unit is essentially persistent unit xml - minus transaction type and list of mapped classes.
 +
Its settings could be overridden with the properties as described above.

Latest revision as of 10:33, 4 November 2010

Partitioning

I think it is incorrect to consider the SessionBroker as a partitioning solution. The purpose of the SessionBroker is for Data Integration, not Data Partitioning. The SessionBroker was designed as a Data Integration solution, initially to support integrating a legacy (mainframe) database (or EIS) with new relational data. Also to provide an aggregated view on a set of a corporation's databases. It is entirely designed to work with heterogeneous data sources, it goal is to provide an integrated view on heterogeneous data, not to provide partitioning, fail-over or scalability. It should not be relabeled or marketed as a partitioning solution, only as a Data Integration solution. We do need a Data Partitioning solution, such a solution would have very different goals and requirements.

James.sutherland.oracle.com 14:33, 4 November 2010 (UTC)

Session Type

The property to set the Session type, such as using a DatabaseSession should not be, "eclipselink.jdbc.single-connection", but "eclipselink.session.type". For SessionBroker, this should be of type "SessionBroker", "DatabaseSession" could also be supported, the default would be "ServerSession", but other types could be supported, including a user defined class "<package>.<class>".

James.sutherland.oracle.com 13:54, 25 October 2010 (UTC)

Configuration

We should not have two (or 5??) different ways to configure this. Only a single logical way. The user should define a persistence unit for each ServerSession and another for the SessionBroker that lists the dependent persistence units.

James.sutherland.oracle.com 13:54, 25 October 2010 (UTC)

The property names should make sense, not be "eclipselink.define.my-set-property.value1". Should be "eclipselink.session.dependents"="pu1, pu2".

James.sutherland.oracle.com 13:54, 25 October 2010 (UTC)

This feature should be developed in 2 stages. Stage 1: Update JPA to use DatabaseSessionImpl, define SessionBroker from two independent persistence units. Stage 2: Support cross persistence unit relationships.

James.sutherland.oracle.com 13:54, 25 October 2010 (UTC)

JPA Configuration Example

--Doug 18:11, 25 October 2010 (UTC) Although originally I had been assuming we would have a persistence unit per data source with a composite data source it does make container managed JPA support challenging. Even more so when we add support for simple configuration of relationships that go between tables in different data sources.

Proposed Config

Within the persistence.xml a secondary data source is defined. This DS couldne JTA, non--JTA, or a native JDBC connection pool.

<persistence-unit name="employee" transaction-type="JTA">
	<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
	<jta-data-source>localJTA</jta-data-source>
 
	<properties>
                <!-- Implicitly define a secondary data source named 'addr-ds' -->
		<property name="eclipselink.jta-data-source.addr-ds" value="addrDS"/>
	</properties>
</persistence-unit>

Within the specified or defaulted EclipseLink ORM xml the data source for entity types not stored in the default DS can be specified.

<entity class="eclipselink.example.jpa.employee.model.Employee" />
<entity class="eclipselink.example.jpa.employee.model.Address" data-source="addr-ds" />

In this example we'll use a secondary native connection pool as the data source.

<persistence-unit name="employee" transaction-type="JTA">
	<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
	<jta-data-source>localJTA</jta-data-source>
 
	<properties>
                <!-- Implicitly define a secondary data source named 'addr-ds' -->
		<property name="eclipselink.jdbc.driver.addr-ds" value="oracle..."/>
		<property name="eclipselink.jdbc.url.addr-ds" value="jdbc:"/>
		<property name="eclipselink.jdbc.user.addr-ds" value="scott"/>
		<property name="eclipselink.jdbc.password.addr-ds" value="tiger"/>
 
                <!-- Implicitly define another data source named 'project-ds' -->
		<property name="eclipselink.jdbc.driver.project-ds" value="oracle..."/>
		<property name="eclipselink.jdbc.url.project-ds" value="jdbc:"/>
		<property name="eclipselink.jdbc.user.project-ds" value="scott"/>
		<property name="eclipselink.jdbc.password.project-ds" value="tiger"/>
	</properties>
</persistence-unit>


Proposed Config - extended

The logical conclusion of the above approach would be an option to define split data sources in EclipseLink ORM xml, too.

<entity class="eclipselink.example.jpa.employee.model.Employee" />
<entity class="eclipselink.example.jpa.employee.model.Address" data-source="addr-ds" />
<entity class="eclipselink.example.jpa.employee.model.Project" data-source="proj-ds" />
<entity class="eclipselink.example.jpa.employee.model.SmallProject" data-source="proj-ds" />
<entity class="eclipselink.example.jpa.employee.model.LargeProject" data-source="proj-ds" />
<entity class="eclipselink.example.jpa.employee.model.HugeProject" data-source="proj-ds" />
 
<data-source name="addr-ds">
    <jta-data-source>Ds1_JTA</jta-data-source>
    <nonjta-data-source>Ds1</nonjta-data-source>
</data-source>
<data-source name="proj-ds">
    <jta-data-source>Ds2_JTA</jta-data-source>
    <nonjta-data-source>Ds2</nonjta-data-source>
</data-source>

To define internal connection pools:

<data-soure name="addr-ds">
	<properties>
		<property name="eclipselink.jdbc.driver" value="oracle..."/>
		<property name="eclipselink.jdbc.url" value="jdbc:"/>
		<property name="eclipselink.jdbc.user" value="scott"/>
		<property name="eclipselink.jdbc.password" value="tiger"/>
	<properties>
</data-soure
<data-soure name="proj-ds">
	<properties>
		<property name="eclipselink.jdbc.driver" value="mysql..."/>
		<property name="eclipselink.jdbc.url" value="jdbc:"/>
		<property name="eclipselink.jdbc.user" value="user2"/>
		<property name="eclipselink.jdbc.password" value="password2"/>
	<properties>
</data-soure>

The secondary "data-source" unit is essentially persistent unit xml - minus transaction type and list of mapped classes. Its settings could be overridden with the properties as described above.

Back to the top