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/UserGuide/JPA/Advanced JPA Development/Data Partitioning"

m (persistence.xml)
m
 
(19 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
----
 +
 +
 +
'''[[Image:Elug_draft_icon.png|Warning]] This page is now obsolete. '''
 +
 +
For current information, please see "Partitioning Annotations" in the ''Java Persistence API (JPA) Extensions Reference for EclipseLink'':
 +
http://eclipse.org/eclipselink/documentation/latest/jpa/extensions/annotations_ref.htm
 +
 +
 +
----
 +
 +
 +
 +
 
{{EclipseLink_UserGuide
 
{{EclipseLink_UserGuide
 
|info=y
 
|info=y
Line 6: Line 20:
 
|api=y
 
|api=y
 
|apis=  
 
|apis=  
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/descriptors/partitioning/package-summary.html Package partitioning]
+
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/Partitioned.html @Partitioned]
 
+
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/HashPartitioning.html @HashPartitioning]
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/sessions/server/ServerSession.html ServerSession]
+
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/PinnedPartitioning.html @PinnedPartitioning]
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/descriptors/ClassDescriptor.html ClassDescriptor]
+
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/RangePartitioning.html @RangePartitioning]
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/mappings/ForeignReferenceMapping.html ForeignReferenceMapping]
+
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/ReplicationPartitioning.html @ReplicationPartitioning]
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/queries/DatabaseQuery.html DatabaseQuery]
+
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/RoundRobinPartitioning.html @RoundRobinPartitioning]
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/sessions/DatabaseLogin.html DatabaseLogin]
+
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/ValuePartitioning.html @ValuePartitioning]
 +
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/UnionPartitioning.html @UnionPartitioning]
 +
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/Partitioning.html @Partitioning]
 +
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/descriptors/partitioning/package-summary.html partitioning package]
 
}}
 
}}
  
 
=Data Partitioning=
 
=Data Partitioning=
  
THIS SECTION IN PROGRESS. PLEASE SEE DISCUSSION.
+
Data partitioning allows for an application to scale its data across more than a single database machine. EclipseLink supports data partitioning at the Entity level to allow a different set of entity instances for the same class to be stored in a different physical database or different node within a database cluster.  Both regular databases, and clustered databases are supported.  Data can be partitioned both horizontally and vertically.
 
+
  
With data partitioning, you can subdivide a database table, index or index-organized table into smaller units. That makes it possible to manage and access those objects at a finer level of granularity, thereby improving manageability, performance, and availability. For example, data partitioning facilitates load-balancing and replicating data across multiple different databases or across a database cluster.  
+
Partitioning can be enabled on an an entity, a relationship, a query, or a persistence unit.
  
 
==Partitioning Policies==
 
==Partitioning Policies==
  
You configure data partitioning using partitioning policies. The different kinds of policies are:
+
To configure data partitioning, use the [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/Partitioned.html <tt>@Partitioned</tt>] annotation and one or more partitioning policy annotations. The annotations for defining the different kinds of policies are:
  
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/descriptors/partitioning/CustomPartitioningPolicy.html <tt>CustomPartitioningPolicy</tt>] - Defines a user defined partitioning policy. Used by metadata to defer class loading to init.  
+
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/HashPartitioning.html <tt>@HashPartitioning</tt>] - Partitions access to a database cluster by the hash of a field value from the object, such as the object's ID, location, or tenant. The hash indexes into the list of connection pools/nodes. All write or read request for objects with that hash value are sent to the same server. If a query does not include the hash field as a parameter, it can be sent to all servers and unioned, or it can be left to the session's default behavior.  
  
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/descriptors/partitioning/FieldPartitioningPolicy.html <tt>FieldPartitioningPolicy</tt>] - Partitions access to a database cluster by a field value from the object, such as the object's ID, location, or tenant. All write or read requests for objects with that value are sent to the server. If a query does not include the field as a parameter, it can either be sent to all servers and unioned or left to the session's default behavior.  
+
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/PinnedPartitioning.html <tt>@PinnedPartitioning</tt>] - Pins requests to a single connection pool/node. This allows for vertical partitioning.
  
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/descriptors/partitioning/HashPartitioningPolicy.html <tt>HashPartitioningPolicy</tt>] - Partitions access to a database cluster by the hash of a field value from the object, such as the object's location, or tenant. The hash indexes into the list of connection pools. All write or read request for objects with that hash value are sent to the server. If a query does not include the field as a parameter, it can be sent to all servers and unioned, or it can be left to the session's default behavior.  
+
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/RangePartitioning.html <tt>@RangePartitioning</tt>] - Partitions access to a database cluster by a field value from the object, such as the object's ID, location, or tenant. Each server is assigned a range of values. All write or read requests for objects with that value are sent to the same server. If a query does not include the field as a parameter, then it can either be sent to all server's and unioned, or left to the session's default behavior.
  
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/descriptors/partitioning/PartitioningPolicy.html <tt>PartitioningPolicy</tt> ] - Partitions the data for a class across multiple different databases or across a database cluster such as Oracle Real Application Clusters (RAC). Partitioning can provide improved scalability by allowing multiple database machines to service requests. (If multiple partitions are used to process a single transaction, JTA should be used for proper XA transaction support.)
+
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/ReplicationPartitioning.html <tt>@ReplicationPartitioning</tt>] - Sends requests to a set of connection pools/nodes. This policy is for replicating data across a cluster of database machines. Only modification queries are replicated.  
  
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/descriptors/partitioning/PinnedPartitioningPolicy.html <tt>PinnedPartitioningPolicy</tt>] - Pins requests to a single connection pool.  
+
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/RoundRobinPartitioning.html <tt>@RoundRobinPartitioning</tt>] - Sends requests in a round-robin fashion to the set of connection pools/nodes. It is for load balancing read queries across a cluster of database machines. It requires that the full database be replicated on each machine, so it does not support partitioning. The data should either be read-only, or writes should be replicated.  
  
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/descriptors/partitioning/RangePartitioningPolicy.html RangePartitioningPolicy] - Partitions access to a database cluster by a field value from the object, such as the object's ID, location, or tenant. Each server is assigned a range of values. All write or read requests for objects with that value are sent to the server. Each server is assigned a range of values. All write or read request for object's with that value are sent to the server. If a query does not include the field as a parameter, then it can either be sent to all server's and unioned, or left to the sesion's default behavior. [In Javadoc, sters (RAC). Partitioning can provide improved scalability by allowing multiple database machines to service requests. (If multiple partitions are used to process a single transaction, JTA should be used for proper XA transaction support.)
+
* [http://www.eclipse.org/eclipselink/api/org/eclipse/persistence/annotations/UnionPartitioning.html <tt>@UnionPartitioning@</tt>] - Sends queries to all connection pools and unions the results. This is for queries or relationships that span partitions when partitioning is used, such as on a ManyToMany cross partition relationship.  
  
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/descriptors/partitioning/PinnedPartitioningPolicy.html PinnedPartitioningPolicy] - Pins requests to a single connection pool. [In Javadoc, not in spec]
+
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/ValuePartitioning.html <tt>@ValuePartitioning</tt>] - Partitions access to a database cluster by a field value from the object, such as the object's location or tenant. Each value is assigned a specific server. All write or read requests for objects with that value are sent to the same server. If a query does not include the field as a parameter, then it can be sent to all servers and unioned, or it can be left to the session's default behavior.
  
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/descriptors/partitioning/RangePartitioningPolicy.html RangePartitioningPolicy] - Partitions access to a database cluster by a field value from the object, such as the object's ID, location, or tenant. Each server is assigned a range of values. All write or read requests for objects with that value are sent to the server. Each server is assigned a range of values. All write or read request for object's with that value are sent to the server. If a query does not include the field as a parameter, then it can either be sent to all server's and unioned, or left to the sesion's default behavior. [In Javadoc, not in spec]
+
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/annotations/Partitioning.html <tt>@Partitioning</tt>] - Partitions access to a database cluster by a custom partitioning policy. A <code>PartitioningPolicy</code> class must be provided and implemented.
  
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/descriptors/partitioning/ReplicationPartitioningPolicy.html ReplicationPartitioningPolicy] - Sends requests to a set of connection pools. This policy is for replicating data across a cluster of database machines. Only modification queries are replicated.
 
 
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/descriptors/partitioning/RoundRobinPartitioningPolicy.html RoundRobinPartitioningPolicy] - Sends requests in a round-robin fashion to the set of connection pools. It is for load balancing read queries across a cluster of database machines. It requires that the full database be replicated on each machine, so it does not support partitioning. The data should either be read-only, or writes should be replicated on the database.
 
 
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/descriptors/partitioning/UnionPartitioningPolicy.html UnionPartitioningPolicy] - Sends queries to all connection pools and unions the results. This is for queries or relationships that span partitions when partitioning is used, such as on a ManyToMany cross partition relationship.
 
 
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/descriptors/partitioning/ValuePartitioningPolicy.html ValuePartitioningPolicy] - Partitions access to a database cluster by a field value from the object, such as the object's location or tenant. Each value is assigned a specific server. All write or read requests for objects with that value are sent to the server. If a query does not include the field as a parameter, then it can be sent to all servers and unioned, or it can be left to the session's default behavior.
 
 
All policies provide an exclusive connection option. This assigns an accessor to the client session on the first query execution and uses that connection for the duration of the session. This ensures that the entire transaction stays on the same node.
 
  
 
Partitioning policies are globally-named objects in a persistence unit and are reusable across multiple descriptors or queries. This improves the usability of the configuration, specifically with JPA annotations and XML.
 
Partitioning policies are globally-named objects in a persistence unit and are reusable across multiple descriptors or queries. This improves the usability of the configuration, specifically with JPA annotations and XML.
  
The persistence unit properties support adding named connection pools in addition to the existing configuration for read/write/sequence.  
+
The persistence unit properties support adding named connection pools in addition to the existing configuration for read/write/sequence.  A named connection pool must be defined for each node in the database cluster.
  
==Data Affinity, Oracle RAC, and JDBC UCP Support==
+
If a transaction modifies data from multiple partitions, JTA should be used to ensure 2-phase commit of the data.  An exclusive connection can also be configured in the EntityManager to ensure only a single node is used for a single transaction.
  
Some cluster-enabled databases define their own DataSource implementation that is cluster-aware. Some support data affinity and integration with a data affinity service such as EclipseLink provides. Oracle RAC is supported through the Oracle JDBC Universal Connection Pool (UCP). UCP supports a single DataSource into the RAC and can perform its own load balancing and fail-over. UCP also supports a data affinity callback API. A callback can be registered to provide UCP a hint as to which node to direct the connection request to.
+
==Clustered Databases and Oracle RAC==
  
A generic DataPartitioningCallback interface is defined in EclipseLink (platform.database.partitioning) to support integration with an external DataSource data affinity. The callback is given a chance to register itself with the DataSource on connect. The PartitioningPolicys set the partition ID into the callback instead of acquiring a connection from a connection pool.
+
Some databases support clustering the database across multiple machines. Oracle RAC allows for a single database to span multiple different server nodes.
 +
Oracle RAC also supports table and node partitioning of data. A database cluster allows for any of the data to be accessed from any node in the cluster. However, it is generally it is more efficient to partition the data access to specific nodes, to reduce cross node communication.
  
A UCPDataPartitioningCallback is included in EclipseLink's Oracle component with a dependency on ucp.jar. It registers with the UCP DataSource and maintains a ThreadLocal to store the current partition ID to pass to UCP when its callback is invoked.  
+
EclipseLink partitioning can be used in conjunction with a clustered database to reduce cross node communication, and improve scalability.
  
 +
To use partitioning with a database cluster to following is required:
 +
* Partition policy should not enable replication, as database cluster makes data available to all nodes.
 +
* Partition policy should not use unions, as database cluster returns the complete query result from any node.
 +
* A DataSource and EclipseLink connection pool should be defined for each node in the cluster.
 +
* The application's data access and data partitioning should be designed to have each transaction only require access to a single node.
 +
* Usage of an exclusive connection for an EntityManager is recommended to avoid having multiple nodes in a single transaction and avoid 2-phase commit.
  
 
+
== Data Partitioning Examples ==
== Configuration Files ==
+
This example partitions the Employee data by location. The two primary sites, Ottawa and Toronto are each stored on a separate database. All other locations are stored on the default database.
 
+
Project is range partitioned by its ID.  Each range of ID values are stored on a different database.
=== orm.xml ===
+
The employee/project relationship is an example of a cross partition relationship. To allow the employees and projects to be stored on different databases a union policy is used and the join table is replicated to each database.
<source lang="xml">
+
<partitioning-policy class="org.acme.MyPolicy"/>
+
<round-robin-policy replicate-writes="true">
+
  <connection-pool>node1</connection-pool>
+
  <connection-pool>node2</connection-pool>
+
</round-robin-policy>
+
<random-policy replicate-writes="true">
+
  <connection-pool>node1</connection-pool>
+
  <connection-pool>node2</connection-pool>
+
</random-policy>
+
<replication-policy>
+
  <connection-pool>node1</connection-pool>
+
  <connection-pool>node2</connection-pool>
+
</replication-policy>
+
<range-partitioning-policy parameter-name="id" exclusive-connection="true" union-unpartitionable-queries="true">
+
  <range-partition connection-pool="node1" start-value="0" end-value="100000" value-type="java.lang.Integer"/>
+
  <range-partition connection-pool="node2" start-value="100001" end-value="200000" value-type="java.lang.Integer"/>
+
  <range-partition connection-pool="node3" start-value="200001" value-type="java.lang.Integer"/>
+
</range-partitioning-policy>
+
</source>
+
 
+
=== persistence.xml ===
+
 
+
<source lang="xml">
+
<!--Need example-->
+
</source>
+
 
+
== Code Examples ==
+
  
 
<source lang="java">
 
<source lang="java">
Line 151: Line 137:
 
</source>
 
</source>
  
 +
<!--
 +
== Configuring Data Partitioning in eclipselink-orm.xml ==
 +
 +
Configure data partitioning in eclipselink-orm.xml, as shown in the following example.
 +
 +
<source lang="xml">
 +
<partitioning-policy class="org.acme.MyPolicy"/>
 +
<round-robin-policy replicate-writes="true">
 +
  <connection-pool>node1</connection-pool>
 +
  <connection-pool>node2</connection-pool>
 +
</round-robin-policy>
 +
<random-policy replicate-writes="true">
 +
  <connection-pool>node1</connection-pool>
 +
  <connection-pool>node2</connection-pool>
 +
</random-policy>
 +
<replication-policy>
 +
  <connection-pool>node1</connection-pool>
 +
  <connection-pool>node2</connection-pool>
 +
</replication-policy>
 +
<range-partitioning-policy parameter-name="id" exclusive-connection="true" union-unpartitionable-queries="true">
 +
  <range-partition connection-pool="node1" start-value="0" end-value="100000" value-type="java.lang.Integer"/>
 +
  <range-partition connection-pool="node2" start-value="100001" end-value="200000" value-type="java.lang.Integer"/>
 +
  <range-partition connection-pool="node3" start-value="200001" value-type="java.lang.Integer"/>
 +
</range-partitioning-policy>
 +
</source>
 +
 +
-->
 +
<!--
 
==Connection Pool Properties==
 
==Connection Pool Properties==
 
* "javax.persistence.jdbc.url"
 
* "javax.persistence.jdbc.url"
Line 177: Line 191:
 
* "eclipselink.connection-pool.<name>.nonJtaDataSource"
 
* "eclipselink.connection-pool.<name>.nonJtaDataSource"
  
=== Deprecated Connection Pool Properties ===
+
-->
  
These properties are now under under the "connection-pool" category and are deprecated.
 
  
* "eclipselink.connection-pool.max"
+
{{EclipseLink_JPA
* "eclipselink.connection-pool.write.max"
+
|previous =[[EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Schema_Generation/Appending_strings_to_CREATE_TABLE_statements|Appending Strings to CREATE_TABLE Statements]]
* "eclipselink.connection-pool.read.max"
+
|up      =[[EclipseLink/UserGuide/JPA/Advanced_JPA_Development|Advanced JPA Development]]
 +
|next =[[EclipseLink/UserGuide/JPA/Advanced_JPA_Development/JPA RESTful Service|JPA RESTful Service]]
 +
|version=2.2.0 DRAFT}}

Latest revision as of 07:33, 17 April 2013



Warning This page is now obsolete.

For current information, please see "Partitioning Annotations" in the Java Persistence API (JPA) Extensions Reference for EclipseLink: http://eclipse.org/eclipselink/documentation/latest/jpa/extensions/annotations_ref.htm





EclipseLink JPA


Data Partitioning

Data partitioning allows for an application to scale its data across more than a single database machine. EclipseLink supports data partitioning at the Entity level to allow a different set of entity instances for the same class to be stored in a different physical database or different node within a database cluster. Both regular databases, and clustered databases are supported. Data can be partitioned both horizontally and vertically.

Partitioning can be enabled on an an entity, a relationship, a query, or a persistence unit.

Partitioning Policies

To configure data partitioning, use the @Partitioned annotation and one or more partitioning policy annotations. The annotations for defining the different kinds of policies are:

  • @HashPartitioning - Partitions access to a database cluster by the hash of a field value from the object, such as the object's ID, location, or tenant. The hash indexes into the list of connection pools/nodes. All write or read request for objects with that hash value are sent to the same server. If a query does not include the hash field as a parameter, it can be sent to all servers and unioned, or it can be left to the session's default behavior.
  • @PinnedPartitioning - Pins requests to a single connection pool/node. This allows for vertical partitioning.
  • @RangePartitioning - Partitions access to a database cluster by a field value from the object, such as the object's ID, location, or tenant. Each server is assigned a range of values. All write or read requests for objects with that value are sent to the same server. If a query does not include the field as a parameter, then it can either be sent to all server's and unioned, or left to the session's default behavior.
  • @ReplicationPartitioning - Sends requests to a set of connection pools/nodes. This policy is for replicating data across a cluster of database machines. Only modification queries are replicated.
  • @RoundRobinPartitioning - Sends requests in a round-robin fashion to the set of connection pools/nodes. It is for load balancing read queries across a cluster of database machines. It requires that the full database be replicated on each machine, so it does not support partitioning. The data should either be read-only, or writes should be replicated.
  • @UnionPartitioning@ - Sends queries to all connection pools and unions the results. This is for queries or relationships that span partitions when partitioning is used, such as on a ManyToMany cross partition relationship.
  • @ValuePartitioning - Partitions access to a database cluster by a field value from the object, such as the object's location or tenant. Each value is assigned a specific server. All write or read requests for objects with that value are sent to the same server. If a query does not include the field as a parameter, then it can be sent to all servers and unioned, or it can be left to the session's default behavior.
  • @Partitioning - Partitions access to a database cluster by a custom partitioning policy. A PartitioningPolicy class must be provided and implemented.


Partitioning policies are globally-named objects in a persistence unit and are reusable across multiple descriptors or queries. This improves the usability of the configuration, specifically with JPA annotations and XML.

The persistence unit properties support adding named connection pools in addition to the existing configuration for read/write/sequence. A named connection pool must be defined for each node in the database cluster.

If a transaction modifies data from multiple partitions, JTA should be used to ensure 2-phase commit of the data. An exclusive connection can also be configured in the EntityManager to ensure only a single node is used for a single transaction.

Clustered Databases and Oracle RAC

Some databases support clustering the database across multiple machines. Oracle RAC allows for a single database to span multiple different server nodes. Oracle RAC also supports table and node partitioning of data. A database cluster allows for any of the data to be accessed from any node in the cluster. However, it is generally it is more efficient to partition the data access to specific nodes, to reduce cross node communication.

EclipseLink partitioning can be used in conjunction with a clustered database to reduce cross node communication, and improve scalability.

To use partitioning with a database cluster to following is required:

  • Partition policy should not enable replication, as database cluster makes data available to all nodes.
  • Partition policy should not use unions, as database cluster returns the complete query result from any node.
  • A DataSource and EclipseLink connection pool should be defined for each node in the cluster.
  • The application's data access and data partitioning should be designed to have each transaction only require access to a single node.
  • Usage of an exclusive connection for an EntityManager is recommended to avoid having multiple nodes in a single transaction and avoid 2-phase commit.

Data Partitioning Examples

This example partitions the Employee data by location. The two primary sites, Ottawa and Toronto are each stored on a separate database. All other locations are stored on the default database. Project is range partitioned by its ID. Each range of ID values are stored on a different database. The employee/project relationship is an example of a cross partition relationship. To allow the employees and projects to be stored on different databases a union policy is used and the join table is replicated to each database.

@Entity
@IdClass(EmployeePK.class)
@UnionPartitioning(
        name="UnionPartitioningAllNodes",
        replicateWrites=true)
@ValuePartitioning(
        name="ValuePartitioningByLOCATION",
        partitionColumn=@Column(name="LOCATION"),
        unionUnpartitionableQueries=true,
        defaultConnectionPool="default",
        partitions={
            @ValuePartition(connectionPool="node2", value="Ottawa"),
            @ValuePartition(connectionPool="node3", value="Toronto")
        })
@Partitioned("ValuePartitioningByLOCATION")
public class Employee {
    @Id
    @Column(name = "EMP_ID")
    private Integer id;
 
    @Id
    private String location;
    ...
 
    @ManyToMany(cascade = { PERSIST, MERGE })
    @Partitioned("UnionPartitioningAllNodes")
    private Collection<Project> projects;
    ...
}
@Entity
@RangePartitioning(
        name="RangePartitioningByPROJ_ID",
        partitionColumn=@Column(name="PROJ_ID"),
        partitionValueType=Integer.class,
        unionUnpartitionableQueries=true,
        partitions={
            @RangePartition(connectionPool="default", startValue="0", endValue="1000"),
            @RangePartition(connectionPool="node2", startValue="1000", endValue="2000"),
            @RangePartition(connectionPool="node3", startValue="2000")
        })
@Partitioned("RangePartitioningByPROJ_ID")
public class Project {
    @Id
    @Column(name="PROJ_ID")
    private Integer id;
    ...
}


Eclipselink-logo.gif
Version: 2.2.0 DRAFT
Other versions...

Copyright © Eclipse Foundation, Inc. All Rights Reserved.