Use @HashPartitioning
to partition 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.
Annotation Elements
Table 2-25 describes this annotation's elements.
Table 2-25 @HashPartitioning Annotation Elements
Annotation Element | Description | Default |
---|---|---|
|
(Required) The name of the partition policy. The name must be unique within the persistence unit. |
|
|
(Required) The database column or query parameter by which to partition queries. |
|
|
(Optional) List of connection pool names across which to partition. |
All defined pools in the ServerSession |
|
(Optional) Specify if queries that do not contain the partition hash should be sent to every database and union the result. |
False |
Usage
All write or read requests for objects with the hash value are sent to the server. Queries that do not include the field as a parameter will be:
Sent to all servers and unioned
or
Handled based on the session's default behavior.
You can enable partitioning on an Entity, relationship, query, or session/persistence unit. Partition policies are globally named (to allow reuse) and must set using the @Partitioned
annotation.
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, you should use JTA to ensure proper two-phase commit of the data. You can also configure an exclusive connection in the EntityManager to ensure that only a single node is used for a single transaction.
Examples
See "@Partitioned" for an example of partitioning with EclipseLink.
See Also
For more information, see: