The primary objective of Slice is to make building distributed database applications with OpenJPA simple.

The existing application or the persistent domain model requires no change to upgrade from a single database to a distributed database environment.

User application decides how the newly persistent instances be distributed across multiple database slices. The data distribution policy across the slices may be based on the attribute of the data itself. For example, all Customer whose first name begins with character 'A' to 'M' will be stored in one database while names beginning with 'N' to 'Z' will be stored in another slice. It is also common to find data distribution policies based on temporal attributes. Slice tracks the original database for existing instances. When an application issues a query, the instances may be loaded from from different database slices. This tracking is important as update to any instance gets committed to the appropriate database.

Each slice can be configured independently with its own JDBC driver. Hence data can be distributed across heterogeneous databases.

All database operations such as query, commit or flush operates in parallel across the database slices.

The query result that includes ORDER BY clause are sorted correctly by merging results from each individual slice.

The database slices participate in a global transaction provided each slice is configured with a XA-complaint JDBC driver, even when the persistence unit is configured for RESOURCE_LOCAL transaction. If any of the configured slices are non-XA-complaint and the persistence unit is configured for RESOURCE_LOCAL transaction then each slice is committed without any two-phase commit protocol. If commit on any slice fails, then atomic nature of the transaction is not ensured.

No relationship can exist across database slices. In O-R mapping paradigm, this translates to the limitation that the closure of an object graph must be collocated in the same database. For example, consider a domain model where Person relates to Adress. Person X refers to Address A while Person Y refers to Address B. Collocation Constraint means that both X and A must be stored in the same database slice. Similarly Y and B must be stored in a single slice. Slice, however, helps to maintain collocation constraint automatically. The instances in the closure set of any newly persistent instance reachable via cascaded relationship is stored in the same slice. The user-defined distribution policy requires to supply the slice for the root instance only.

Slice can not query that includes any aggregate projection such as SUM(), MIN(), AVG.

&homer;